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

23/10/2014

REST isn’t responsive enough.

Why?

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.

Responses

Emmanuel Roubion says:
October 23, 2014

Hey Tsahi,

However, this is still possible to use a websocket with a REST API as well. Both are not mutually exclusive. I mean:
1. you have your classic REST API, for classic REST request/responses.
2. you use the same API over websocket, subscribing to REST ressources “events” to make the server push them to you.

E.g., you can imagine the benefit to check your Instant Messages history in classic REST, then subscribe to its events over you websocket, to be notified in real time, with the same REST API and objects.

This avoids the need of another JS API for the “connected” protocol, all stays in the REST API.

(and I speak of a real case: ours!)

Cheers,
Emmanuel.

Reply
    Tsahi Levent-Levi says:
    October 23, 2014

    Emmanuel,

    Thanks. I tried to explain that in my post, but I guess I didn’t do a great job of it 🙂
    The WebRTC API platforms usually have a mix of JavaScript and REST in them.

    Reply
Matthew Hodgson says:
October 26, 2014

In our experience, REST is absolutely fine for setting up realtime communication channels – and in fact the prevalence of plain old HTTP makes it a much better baseline than relying on websockets actually working.

Setting up a VoIP call over REST should be a single roundtrip – the HTTP overheads (especially with SPDY and HTTP/2.0) are minor, and certainly no worse than SIP or Jingle. The fact that Websockets eliminate the HTTP header overhead per-request is a fairly minor optimisation.

Other than eliminating header overhead, what ways of “optimising responsiveness” are you thinking of for signalling protocols that REST doesn’t give you already? 🙂

Reply

Comment