Why REST isn’t Enough for Real Time and WebRTC API

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:

1. REST APIs to access the backend for management related calls
2. JavaScript APIs for the WebRTC/session related stuff

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. To that end, you need to either use something like XHR or SSE, which are "old school" or go for Websocket as your transport mechanism assuming you want better scaling of your backend servers. 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. So where does the JavaScript API come to play? Unlike VoIP, where the way to describe a protocol is to explain what flows over the network, the protocol part here gets "hidden" from the developer by giving him a nice API wrapper on top of it. A JavaScript file that implements the signaling protocol on top of the Websocket which exposes the API. There is a distinct difference here:

1. The backend REST APIs are on the side of the server - the web server listens and waits for incoming requests
2. The JavaScript APIs are a file provided by the vendor who developed the web server, and the APIs are in effect implemented on the client side and hide the protocol used between the client and the server

The end result? Something that can be optimized for responsiveness, which is what we are looking for in real time services. If you ask me, in the future, there will be both REST based APIs and a growing number of Websocket+JavaScript APIs and they won't be limited to WebRTC.