Differences between websockets and long polling for turn based game server

I am writing a server for an iOS game. The game is turn-based and the only time the server needs to push information to the client is to notify of the opponent's move.

I am curious if anyone could comment on the performance and ease of implementation differences between using WebSockets and long polling. Also, if I used WebSockets, should I only use it to receive information and send POST requests for everything else, or should all communication be through the WebSocket?

Additionally, is there anything extra to consider between WebSockets and long polling if I am interested in also making a web client?

For anyone else who may be wondering, it could depends on how long typical interactions go between events?

Websocket: Anything more than a few tens of seconds, I don't think keeping a websocket open is particularly efficient (not to mention that IIRC it would disconnect anyway if the app loses focus)

Long polling: This forces a trade-off between server load (anything new now? how about now? ...) and speediness of knowing a change has occurred.

Push notifications: While this may be technically more complex to implement, it really would be the best solution IMO, since:

• the notification can be sent (and delivered) almost immediately after an event occurs
• there is no standby server load (either from open websockets, or "how about now?" queries) - which is especially important as your use-base grows
• you can override what happens if a notification comes in while the user is in-app

> should I only use it to receive information and send POST requests for > everything else

Yes, you should use WebSockets to fetch real-time updates only, and REST APIs to do BREAD stuff.

> should all communication be through the WebSocket?

Short answer: No,

Check this article from PieSocket for more information about the best use cases for WebSockets. What Is WebSocket: Introduction And Usage