- Blend naturally with RESTful API design.
- Optionally support WebSockets, but do so without abandoning established API principles.
- Keep it simple. It should be possible to
How it works
The client makes a GET or HEAD request to discover the capabilities of a resource:
For example, the
value-wait link indicates that it’s possible to make a GET request that hangs open until the value changes (this is known as long-polling). The
multiplex-socket link is for WebSocket connectivity. Versioning is handled using ETags.
What’s nice about LiveResource’s long-polling mechanism is that it is simple and stateless. It’s just a GET request with
There is no complicated socket session emulation. This means you can even use
Of course, LiveResource’s WebSocket mechanism can be used for greater network efficiency.
If a resource doesn’t advertise any push capabilities, then the client will resort to plain polling. This means that a LiveResource client is compatible with any resource on the Internet, and automatically becomes more efficient if push capabilities are discovered.
See the full spec here.
There is a test server at
test.liveresource.org. You can use it to play around with the protocol or test client code against. For example, there is a resource that reports the current time.