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

By: Matthew Hodgson

Matthew Hodgson — Sat, 25 Oct 2014 23:23:59 +0000

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? 🙂

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Thu, 23 Oct 2014 18:18:53 +0000

In reply to Emmanuel Roubion.

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.

By: Emmanuel Roubion

Emmanuel Roubion — Thu, 23 Oct 2014 15:02:53 +0000

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.