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.
EDIT: For more clarity around Kafka, I'd say that Robert's answer suffices, but to elaborate: Kafka is just my preference so that's what I've opted for including in the answer, it will come at an overhead of having to provide additional resources for it (and Zookeper), but it's the perfect fit for cases such as this. I've built numerous systems revolving around Kafka as you can simply knit services onto it and establish flows of data between services through topics (in a persistent and distributed way!). Anyways, I feel like we're diverging from the original question, you can read about it on their official site.