REST isn’t responsive enough.
REST is what they teach today about APIs. You want open APIs for your product or service? Use REST.
SOAP was then. REST is now.
To explain simply, REST uses the same HTTP request and URLs mechanisms that we all use daily when we access our browsers. It is easy to start with and easy to understand (as long as the REST APIs are well thought of and designed properly).
When I did the rounds of WebRTC API Platform vendors for my report, I usually asked each vendor what signaling did he use and how his system get accessed.
They usually had 2 sets of APIs for their platforms:
- REST APIs to access the backend for management related calls
How come? Why not REST for both? Why not just use REST for your WebRTC API?
The simple answer is that REST is usually used for one way communication – when a client reaches out to a server to request something. And with real time communications we need something that can easily support requests initiated by the server itself.
While I regard XHR and SSE as hacks, and Websocket as the actual solution to the problem, they all server similar purpose – to enable messages to flow between the browser and the web server in either direction. This makes it flexible enough for real time communications which in itself also flows in either direction.
There is a distinct difference here:
- The backend REST APIs are on the side of the server – the web server listens and waits for incoming requests
The end result? Something that can be optimized for responsiveness, which is what we are looking for in real time services.