Is it good enough to just define a REST end-point (say ping) which will return the status of the server and API? The client side will call this REST API every few seconds.
Depends. It's important matching frequency vs concurrency because a handful of clients doing pings to the server might not cause a noticeable load but hundreds or thousands of clients could. Imagine 1000, 10000, 100000 clients sending pings every 3 seconds. The peak is likely to make your server sweat.
HTTP connections are costly to perform on both sides, reliable but slow and overall they are blocking I/O communications. Something you need to mitigate if your system is frequently exposed to a high concurrency. However, if the concurrency is low a RESTful solution is more than enough. It's reliable, secure and it scales well.
On the other hand, communications through WebSockets are not blocking, they perform quite well with high concurrency where client and server exchange little information and the computing time is short on both sides. Such is the case of heartbeats. Moreover, WebSockets implements a "Ping-Pong" protocol within its "Control frame" through which you could achieve the expected behaviour. For more information, check out the RFC.
In my opinion, whether to use WebSockets or HTTP REST endpoints will depend on the concurrency and its frequency.
I would also consider a couple of things:
Whether clients can (or can not) adopt new communication protocols. If they can not there's no room for discussion.
Whether the infrastructure allows you to expose WebSockets. I have worked for customers with very strict network rules where almost anything (but SMTP, SFTP, HTTPS) were unallowed.
Let's say we still expect high concurrency but, for some reason, we don't implement WebSockets. If I were requested to do it this way, I would rather make the server to "push" its state somewhere at a fixed delay. Then I would move the responsibility to expose the state to another service capable of Async I/O (as for instance NodeJS). Then, I would redirect requests to this new service. In other words, redirect the stress of the pings to a dedicated and performant service.
I would tell clients to hold the last state retrieved. If the state doesn't change in further requests, it's likely the service is not reporting its state and something is wrong on the server-side. This approach scales well since you hold the state of several services without affecting their respective performance and you can track them, as a whole or independently, from a single endpoint.