I'd say the 2nd solution is feasible, but, in any event, an *event* needs to be sent to the WS server which would broadcast a message to all clients connected. In an ideal world, I'd say a stream/message queue in between the WS Server and API would be a good way to handle passing events between those services, which would aid in creating a more message-driven architecture if you're into that kind of stuff. 
So the architecture would be something along the lines of: 

**(API SERVER) ----> (message queue/streaming platform) ---> (WS SERVER) ----> (n clients)** 

Where the API server receives a request, adds stuff to the database, places a message to the streaming platform/queue. The WS server pulls messages from the streaming platform (say that it's a *pull-based* platform like Kafka), and, on each message(event), sends a message to all clients via WebSocket communication. 

There's really no ideal way of handling this, but the architecture that you currently have in place seems to be OK for creating a microservice architecture which is message-driven, you can even stretch it to a full-blown Reactive architecture ideally.

You *could* technically also have a service that would check the database for changes (via `CHECKSUM`) or something alike and then, again, notify the WS server to broadcast to clients, but, as you already have a REST API, I'd say go with the given approach.