WebSockets versus REST… fight!
Where will WebSockets be on this InfoQ chart, in three years time?
On 8th December 2011, a little known (but growing in awareness) standard called “WebSockets” was upgraded to W3C Candidate Recommendation status. That is one small step shy of becoming a fully ratified web standard. And just to remove any remaining possible doubt: Next-gen platforms and frameworks such as Windows 8 and .NET 4.5 (at three levels: System.Net, WCF and ASP.NET) already have deeply nested support, and they aren’t even beta yet!
After reading up about the standard in detail and absorbing the various online discussion around it, it is becoming increasingly clear to me that this standard is going to steal a large chunk of mind share from RESTful web services. What I mean is that there will come a stage in product development where somebody will have to ask the question:
Right guys, shall we use WebSockets or REST for this project?
I expect that WebSockets will, within a year or two, begin stunting the growth of RESTful web services – at least as we know them today.
What are WebSockets?
They are an overdue and rather elegant protocol extension for HTTP 1.1 that allows what is fundamentally a bi-directional TCP data stream to be tunnelled over a HTTP session. They provide a built-in implementation of TCP message framing, so developers don’t need to worry about any boilerplate code stuff like that when designing their application protocol.
Why are WebSockets a threat to RESTful web services?
From the last few years of working on projects that expose RESTful web services, I have noticed a few shortcomings. I should probably make clear that I’m not claiming that WebSockets answers all those shortcomings. I’m merely suggesting that REST is not the silver bullet solution that it is often hyped up to be. What I am saying is that there is definitely space for another player that can still operate at “web scale”. WebSockets have more scope to be a little more like a black box or quick’n'dirty solution than REST which requires a more design up-front approach due to versioning and public visibility concerns. Always use the correct tool for the job, as they say.
Sub-par frameworks
They might claim REST support but they still haven’t truly “groked” it yet, in my opinion. WCF REST is a good example of this. Admittedly, the WCF Web API for .NET is starting to get close to where things should be, but it is not yet production ready.
Perhaps even more serious is the lack of widespread cross-platform RESTful clients that work in the way that Roy prescribed; of presenting an entry point resource that allows the client to automatically discover and autonomously navigate between further nested resources in a sort of state machine fashion. A single client framework that can operate with hundreds of totally different RESTful web services from different organisations. This does not exist yet, today. This is why so many big providers of RESTful web services end up seeding their own open source projects in various programming languages to provide the essential REST client.
Enterprise loves SOAP (and other RPCs)
Third-parties that want to use your web services often prefer SOAP over REST. Many haven’t even heard of REST! WebSockets are a message-based protocol allowing for SOAP-like RPC protocols that enterprise seem to adore so much. Hell there’s nothing stopping actual SOAP envelopes being transferred over a WebSocket!
This might not be the case if you’re operating in an extremely leading edge market such as perhaps cloud computing where everyone is speaking the same awesomesauce.
Complex domain models
Mapping out complex domain models onto REST can be slow and labourious. You’ll find yourself constantly having to work around its architectural constraints. Transactions, for example, can be a particular problem. Of course, this is partly related to the first problem (sub-par frameworks) but one cannot reasonably expect transaction support in a REST framework. What is probably needed is a set of common design patterns for mapping domain models to REST. And then an extension library for the framework that provides reusable implementations of those patterns. But alas, none of this exists yet.
Text-based formats
JSON/XML (for reasons unknown) are commonly used with REST and these are of course text-based formats. This is great for interoperability and cross-platform characteristics. But it is not so great for memory and bandwidth usage. This especially has implications on mobile devices.
You’ll find yourself running into walls if you try to use something that isn’t JSON or XML, at least that is my experience with current frameworks.
Request-response architecture of HTTP
Fundamentally, REST is nothing more than a re-specification of the way HTTP works and a proposal of a design pattern to build applications on top of HTTP. This means it retains the same statelessness and sessionless characteristics of HTTP. It therefore precludes REST from being bi-directional where the server could act as the requester of some resource from the client, or sender of some message to the client. As a result it requires “hacks” to be used to emulate server-side events, and these hacks have bad characteristics such as high latency (round trip time) and are wasteful of battery life.
Public visibility, versioning concerns
Sometimes having everything publicly visible is not what you want. People start using APIs that you don’t want them to use yet. You have to design everything to the nth degree much more. Have a proper versioning strategy in place. It encourages a more discerning approach to software development, that is for sure. Whilst these are usually good things, they can be a hindrance on early stage “lean agile” projects.
What can WebSockets do that is so amazing?
The fact that there will soon be a second player in this space suggests that there will be rebalancing of use-cases. WebSockets will prove to be disruptive for several reasons:
True bi-directional capability and server-side events, no hacks
Comet, push technology, long-polling etc in web apps are slow, inefficient, inelegant and have a higher potential magnitude for unreliability. They often work by requesting a resource from the server, causing the server to block until such a time that an event (or events) need to be transferred back to the client. They can be unreliable because the TCP connection could be teared down by a intermediate router during the time it is waiting for the response. Or worse, a proxy server might deliberately time out the long-running request. As such, many implementations of this hack will use some kind of self-timeout mechanism so that perhaps every 60 seconds they will reissue the request to the server anyway. This has implications on both bandwidth and battery usage.
The true bi-directional capability offered by WebSockets is a first for any HTTP-borne protocol. It is something that neither SOAP nor REST have. And which Comet/push/long-polling can only emulate, inefficiently. The bi-directional capability is inherently so good that you could tunnel a real-time TCP protocol such as Remote Desktop or VNC over a WebSocket, if you wanted.
Great firewall penetration characteristics
WebSockets can tunnel out of heavily firewalled or proxied environments far easier than many other RPC designs. I’m sure I’m not alone in observing that enterprise environments rarely operate their SOAP services on port 80 or 443.
If you can access the web on port 80 without a proxy, WebSockets will work.
If you can access the web on port 80 with a proxy, WebSockets should work as long as the proxy software isn’t in the 1% that are broken and incompatible.
If you can access the web on port 443 with or without a proxy, WebSockets will work.
I strongly suspect that there will be a whole raft of new Logmein/Remote Desktop and VPN solutions that are built on top of WebSockets, purely because of the great tunnelling characteristics.
Lightweight application protocols and TCP tunnelling
There is the potential for extremely lightweight application protocols, in respect of performance, bandwidth and battery usage. Like REST, the application schema/protocol isn’t defined by the standard; it is left completely wide open. WebSockets can transfer either text strings or binary data. It is clear that the text string support was included to aid in transferring JSON messages to JavaScript engines which lack the concept of byte arrays. Whilst the binary support will be most useful tunnelling TCP streams or for custom RPC implementations. After a WebSocket session is established, the overhead per message can be as small as just two bytes (!). Compare that to REST which has a huge HTTP header to attach to every single request and response.
How will the use-cases of REST change?
I believe that REST will lose a certain degree of its lustre. Project teams will less eagerly adopt it if they can get away with a bare bones WebSocket implementation. REST will probably remain the default choice for projects that need highly visible and cross-platform interoperable web services.
Projects without those requirements will probably opt for WebSockets instead and either run JSON over it, or use a bespoke wire protocol. They will particularly be used by web and mobile applications for their back-end communications i.e. data retrieval and push-events. Windows 8 “Metro” applications will need to use them extensively.
I suppose you could summarise that as:
- REST will be (and remain) popular for publicly visible interfaces.
- WebSockets will be popular for private, internal or “limited eyes only” interfaces.
Note: By “public” and “private” I am not referring literally to some form of paid/subscription/membership web service. I am referring to the programming API contract and its level of exposure to eyes outside of your development team or company.
Conclusion
Even though they are competing, the good thing is that REST and WebSockets can actually co-exist with one another. In fact, because they are both built upon HTTP fundamentals they will actually complement each other. A RESTful hypermedia resource could actually refer to a WebSocket as though it were another resource through a ws:// URL. This will pave the way for new RESTful design patterns and framework features. It will allow REST to remedy some of its shortcomings, such as with transaction support; because a WebSocket session could act as the transactional unit of work.
The next year is going to be very interesting on the web.
[...] WebSockets versus REST… fight! (Nathan Evans) [...]
You make some interesting points but you don’t establish on what basis would REST (an architectural style) and Web Sockets (a technical spec) be considered alternatives to one another. No doubt that the use of Web Sockets may mandate that another architectural style come into play such as an event driven architecture, but at this point, you begin to have many of the same challenges you listed about REST, such as poor implementations, poor tooling, and it will always be difficult to design the right type of messages/events for a complex domain model. The choice between a RESTful architecture or an event driven architecture is more likely to come down to whether you need push or pull functionality rather than whether one is easier to implement than the other.
[...] This is a slight continuation of the previous WebSockets versus REST… fight! post. [...]
I don’t think REST and WebSockets are competing technologies, I rather see them as complementary.
Also, there is a big problem with WebSockets: it’s not 1% proxies that don’t support it, it’s more like 95% of unsupported proxies, especially in mobile networks – where the growth is – which do heavy proxying to their devices. I think that, until WebSocket is really well supported in mobile networks, comet/long-poll won’t die.
@Kris, WebSockets are useful for bi-directional communications and constant streaming/constant updates. If you want to fill a select statement, use REST. If you have a scrolling display of news headlines that continues until the user switches pages, consider WebSockets.
What is represented in y-axis in your “Where will WebSockets be on this InfoQ chart, in three years time?” graph?
You’d have to ask InfoQ. I would assume it is the number of projects using those technologies, based upon some survey they conducted at some point.
When an article starts with a link that points to the IETF but is labelled as “W3C”, it’s not a good sign. When I quickly scan it and it ends by saying WebSockets is “built upon HTTP fundamentals”, I stop reading.
“The WebSocket protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.”
Source: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-1.7
This is only to allow reusing the 80/443 ports, which was a requisite for “high penetration”: faking an HTTP request to establish a (SSL/TLS) connection and tunnel through it, passing through HTTP proxies and firewalls, including “Enterprise” ones that only let port 80 and 443 open.
Wow, hip-fire pedantry.
Though the IETF/W3C mix-up is fair enough. I had the IETF document open and it is presented better than the W3C one so I linked to that instead. It’s all about the version 17 specification, so what does it matter?
But yes, it is built upon HTTP fundamentals. Of course, what “fundamentals” actually means is open to interpretation if you only read the conclusion. The article makes this clear very early on:
“They are an overdue and rather elegant protocol extension for HTTP 1.1 that allows what is fundamentally a bi-directional TCP data stream to be tunnelled over a HTTP session. They provide a built-in implementation of TCP message framing, so developers don’t need to worry about any boilerplate code stuff like that when designing their application protocol.”
The stuff you mentioned about 80/443, firewalls, proxy, tunnelling etc is already covered in the article.
Try reading the article; it might make more sense to you.
The example about newsfeed is not really a good use of Websockets. There is a better alternative for feed of information which is coming from the server at random pace: server sent events.
IMHO WebSockets should replace the most part of http traffic. Have you ever developed UIs with Microsoft Visual Basic? (Let me tell you I am not a Microsoft fan) VB UI development is simply EASY. Why not to migrate that easiness to the web? Simply think that instead of having the screen rederization and the screen event handling in the same machine, they are separated, and a serialized bidirectional slow channel is between them. Let’s suppose there is a kind of server and broker in the browser and the first http request enables the server to establish a bidirectional connection with the website? In that way, the server can send to the browser whatever needed and the browser render them and when a browser event happens, it is sent to the website server. In this way we can forget lots of technology tricks, lots of useless network traffic and lots of unneeded server runtime. The key is a reliable bidirectional comm channel and that is the websocket promise.
Please, use websockets to increase web development productivity and not to keep running web with unefficient frameworks.
[...] Read full article Tagged as: HTML5, REST, websocket Comments Off Comments (0) Trackbacks (0) ( subscribe to comments on this post ) [...]