68

I am planning to develop a web based chat application which takes in ReSTful requests, translate them to XMPP and deliver them to an XMPP server.

Using websockets for this kind of chat based application looked promising as the events (or responses) can be delivered asynchronously. But if I use websockets as the underlying protocol for transferring the requests from the browser, can this still be considered as a ReSTful design? If yes, how are the URIs, verbs (GET, POST...), parameters represented in the websocket message? Wrap them in an xml/json and send it?

Also, ReSTful architecture states that no session state will be stored on the server. But here in this case when an XMPP client session is created, the state of this session will be stored on the server (violating the stateless constraint)

Krishna Chaitanya P
  • 1,115
  • 3
  • 9
  • 17

8 Answers8

69

REST is an architectural style that does not impose a protocol. So yes, you can do REST with Web Sockets, REST with HTTP and REST with FTP if you like.

The main reason to use HTTP is that it is easy and fairly simple to communicate with any component or programming language via HTTP and also because HTTP supports distributed environments with multiple intermediaries: proxies, firewalls...; So you can deploy your service on any topology and anyone will be able to access it.

My rant: If you are a RESTliban and Roy Fielding’s dissertation is the source of truth, verbs are never acknowledged as part of the semantic. URIs are the semantic. The usage of different verbs for different actions has been an elegant evolution of REST over HTTP, but not part of the "truth". You can check the scenario of rest over HTTP evaluated by Roy in chapter six of his dissertation. No mention to verbs. And notice it is an evaluation scenario, not the specification.

TLDR;

If you need realtime two way communications via the internet and the client is a web browser, the best choice is Web Sockets. You could then implement an application level protocol on top of web sockets to implement a RESTful Web Service.

J P
  • 3,692
  • 2
  • 27
  • 37
Daniel Cerecedo
  • 5,283
  • 4
  • 32
  • 46
17

Yes. You can use REST over WebSocket with library like SwaggerSocket.

jdelobel
  • 235
  • 2
  • 7
  • No. Swagger is just HTTP over websockets, not really REST. – gentimouton May 16 '14 at 19:30
  • 5
    @gentimouton All he said was you can use Swagger to interface with REST services. He never stated swagger was REST... You use HTTP to interface with REST, that's whole point. – Slight Jul 28 '16 at 15:40
9

Why would you want to build a REST API on top of socket? IMHO the benefit of a REST API is to leverage standard HTTP protocol possibilities like stateless requests, semantic verbs like GET, DELETE to build an API that can be easily understood by (client) developers. Since sockets do not offer HTTP verbs and so on, you would build some kind of HTTP layer for sockets which is IMHO not reasonable.

In case you would really build such a thing, I'd recommend to use the HTTP protocol as a blueprint and implement the socket protocol like HTTP.

saintedlama
  • 6,488
  • 1
  • 25
  • 42
  • 11
    So, how would one achieve realtime communication with REST? The idea of having REST over WebSockets is more or less legitimate. I would like to have REST semantics with realtime communication. However, I'm starting to think these two things are quite incompatible. – miguelcobain Dec 19 '12 at 10:59
  • 5
    @miguelcobain I know this is really late, but the whole concept of REST is based on stateless requests. There is no real-time communication in REST. – Davy8 Mar 26 '13 at 12:03
  • 4
    @Davy8 So, you mean that when someone chooses to use REST, he will never be able to achieve real-time updates? Are we stuck with the old interval based server polling techniques? – miguelcobain Mar 26 '13 at 12:11
  • 4
    Imagine that the client could expose endpoints itself. Let's say, when a new "fruit object" is available on the server, the server could "POST" to the clients that new update. Other clients could retrieve it via HTTP GET like they always could. I think that these both side endpoints could be the key to achieve real-time with REST. – miguelcobain Mar 26 '13 at 12:19
  • 1
    +1. GET, PUT, POST, DELETE are analogous with pull, push, connect, disconnect, so you could use the same words with sockets too... – inf3rno Oct 20 '13 at 23:22
  • 4
    REST over websockets makes a lot of sense, actually. You could implement a REST layer to keep all of the benefits of a standard API while also getting the benefits of websockets (less data overhead and data pushing). I'm surprised you got as many upvotes as you did. – Spencer Dec 05 '15 at 18:50
  • 1
    I too am surprised. Websockets allow request pipelining, a feature officially supported by HTTP/1.1 but not actually implemented by any browsers. – Arran Cudbard-Bell Jan 27 '16 at 16:57
  • 7
    @saintedlama this answer is wrong as said by another answer it's an architectural style shouldn't depend on a protocol – user310291 Apr 25 '16 at 15:58
  • 1
    @miguelcobain Is [`resthooks`](https://github.com/zapier/resthooks) what you meant by that? – d4nyll Jun 29 '17 at 22:41
2

REST architectural style mostly presumes 2 entities viz. client and server.

As we move more towards real time web and development of reactive systems WebSocket would prominently start replacing usage of REST API's.

WS allows data push and pull which dismisses the concept of server and client.

STOMP,AMQP ,XMPP can be used as messaging protocols.

The data itself maybe JSON or Google protocol buffers or maybe Apache Avro.

WebSockets is not tied to web servers but can be developed in stand alone apps like mobile apps or desktop apps too.

Rohitdev
  • 822
  • 6
  • 15
1

I don't understand why you would convert XMPP into REST and then run REST over WS. The point of WebSocket is to take the XMPP protocol directly to the browser, thereby avoiding all of the translation issues.

There are JavaScript libraries that can talk XMPP from the browser to the server. All you need is to proxy the XMPP traffic from WS over into TCP and then straight into your XMPP server. Kaazing has a gateway that allows you to do this.

If you want to use open source, you will need to write a JavaScript XMPP library. There are examples that show how to write a JS library for simple protocols. You just have to find one and extend the concept to the XMPP protocol.

So to recap, here are the way the architecture would look:

Your XMPP Client code <-> XMPP JavaScript Library <-> WebSocket over http <-> WebSocket to TCP Proxy <-> XMPP Server

where the XMPP Client code and the XMPP JavaScript Library runs in the browser, and the WS to TCP proxy along with the XMPP server are all server-side.

Michel Floyd
  • 16,271
  • 4
  • 21
  • 38
Axel
  • 787
  • 4
  • 9
  • 1
    There is no XMPP on the client side. The idea is to eliminate the need for a web developer to understand/have a knowledge of XMPP. He just needs to have an idea of IM and Presence. Examples:To create a session the web developer in his widget/application sends a POST to some URI, with his username and password, and the "WS to TCP Proxy" in your terms will convert this to an XMPP message and send it to the XMPP Server. – Krishna Chaitanya P Nov 16 '12 at 04:41
  • One more example: To update presence a PUT is sent to a URI say /proxy/presence and the proxy converts it to an XMPP presence packet and sends it to the XMPP server. Similarly a message: A POST is sent to URI /proxy/message and the proxy converts it to an XMPP message, sends it to the XMPP server which in turn delivers it to the recipient. The reason for using REST is that it will be easy for the web developer using the API to create chat applications. – Krishna Chaitanya P Nov 16 '12 at 04:49
  • XMPP isn't hard to understand, depending on the user friendliness of the javascript XMPP client library, the API is actually easier to use and more robust than wrestling with REST. People tend to be afraid of what they dont understand and therefore try to stick with what they know, in this case REST, even if it makes it more complicated and inefficient. I suggest you take a few minutes to see how easy it is to actually use XMPP. There really is no reason for introducing a bunch of inefficiencies and extra overhead by converting XMPP to REST. It's a lot more work and will limit your creativity. – Axel Nov 19 '12 at 19:26
1

I understand this post is really old, but wanted to interject a bit further on the notion that "So if I choose a REST architecture I forfeit the ability for real-time communications?".

In a word, no. A number of REST style implementations I have had experience with leverage REST for compatibility, discoverability, and as a means to scale across different devices in the shadow of IoT.

However, in addition to using WS in addition to REST to facilitate near real-time transmission. There are also a number of abstractions which really help with this and allow you to focus on building your API and deciding how the RT components of the consuming applications should operate.

I would suggest taking a look at things like Tibco Smart-Sockets, or SignalR if you're looking to build a REST API and would like to avoid re-creating the wheel for your RT needs.

ibUptown
  • 552
  • 3
  • 12
1

I created a project that adds callbacks to the web socket send function: https://github.com/ModernEdgeSoftware/WebSocketR2

Message IDs are established so the client can implement callbacks. It handles message retries after timeouts as well as reconnects to the server if the connection gets dropped. You can then structure you payload to be as RESTful as you want by adding verbs and paths.

This is similar to when a video game studio uses UDP to achieve the speeds they need, but their net code implements a lot of TCP like features for reliability.

Neo
  • 982
  • 7
  • 12
0

I just spot new topic on the blog of one company who providing cloud solution and "Server-end/Service as a Platform" (SaaS) for games.

I'm not advertising this company, nor I used them, so I don't even know how good or bad they are.

However, they very clearly explain reasons and what are the benefits of using WebSockets in REST Have a read on their blog

Briksins
  • 1,512
  • 1
  • 12
  • 29
  • Please ensure that the meaning of the blog is represented here because websites can go offline. – Fire Mar 10 '20 at 16:19
  • Well... there too much info to represent here, and I don't want copy/paste and be involved in plagiarism. There is a link to the official source and it is enough. If that blog will go down we always have https://web.archive.org/ ;) – Briksins Mar 15 '20 at 00:19