Nathan Evans' Nemesis of the Moment

WebSockets versus REST… fight!

Posted in .NET Framework, Software Design by Nathan B. Evans on December 16, 2011

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.

About these ads

35 Responses

Subscribe to comments with RSS.

  1. [...] WebSockets versus REST… fight! (Nathan Evans) [...]

  2. Kris said, on December 19, 2011 at 3:10 PM

    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.

  3. [...] This is a slight continuation of the previous WebSockets versus REST… fight! post. [...]

  4. Francisco said, on December 21, 2011 at 1:51 PM

    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.

  5. Charles Wise said, on December 21, 2011 at 2:05 PM

    @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.

  6. Ari said, on December 23, 2011 at 4:55 PM

    What is represented in y-axis in your “Where will WebSockets be on this InfoQ chart, in three years time?” graph?

    • Nathan Evans said, on December 23, 2011 at 5:35 PM

      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. :)

  7. Thomas Broyer said, on December 29, 2011 at 4:36 PM

    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.

    • Nathan Evans said, on December 29, 2011 at 10:13 PM

      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.

  8. karl said, on January 9, 2012 at 1:07 PM

    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.

  9. Aniceto Pérez said, on January 26, 2012 at 12:31 PM

    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.

  10. [...] Read full article Tagged as: HTML5, REST, websocket Comments Off Comments (0) Trackbacks (0) ( subscribe to comments on this post ) [...]

  11. [...] fits into the architectural style of the Web: REST. Some, such as Nathan Evans, go so far as to suggest that WebSockets could overshadow [...]

  12. clive boulton said, on February 27, 2012 at 9:38 AM

    Another indicator WebSockets rises is the Browser fades.

    iOS / Metro are being back-fitted into OSX / Windows, after successfully incubating JavaScript as the programing language on the client, the Browser is no longer needed for Apps. Yet for developer productivity, JavaScript is also moving to the server in NodeJS, providing the canonical era programming language. Using the WebSockets protocol.

  13. Aniceto Pérez y Madr (@aperezymadrid) said, on February 27, 2012 at 10:05 AM

    I think marketplaces are a good thing. The OS maker defines it’s services, developers must adhere to them and that implies wich harwdware and OS versions are supported. Developers don’t need to make software compatible with every thing, only with a few devices. Older devices, newer devices or different devices are handled elsewere, according to it’s hardware and API capabilities. Locally installed apps are good and are not exposed to browser limitations. Give them the ability to exchange data via websockets is nearly the same as using raw sockets.
    But browser based apps wil grow. Browser capabilities are growing dramatically and websockets is a good addition. But the dark side of the browsers is http. Let’s use http as a bootstrap protocol and then switch all communications to a websocket connection. Simple apps may not need a permanent ws connection. Others, may be yes. But bear in mid that the more app you put in the browser more vulnerable it is. Besides, if productivity is what all of us want, it’s more productive to put as much app as possible in the server than in any of the client browsers: many brands, many versions, many OS…

  14. Alessandro Alinone said, on February 27, 2012 at 7:04 PM

    Nathan, regarding your comparison between WebSockets and Comet, I should add that the major difference is in the upstream link. If the Comet solution implements HTTP streaming well (and it’s not easy), the downstream link is extremely efficient and reliable. But it’s impossible to implement real streaming for the upstream link over HTTP. It can be simulated with advanced mechanisms that reduce latency a lot but, I agree, it is still not streaming. For most real-time Web applications, the downstream link has been much more important than the upstream link (in terms of message throughput), but there is now an increasing ecosystem of collaborative applications and games where the upstream link is important as well. So, a good real-time Web server must now be able to support WebSockets and fall back to HTTP Streaming and HTTP Long Polling dynamically.

    I detailed my perspective on this topic a few months ago on Comet Daily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/

  15. [...] Nathan Evans: 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. [...]

  16. WebSockets versus REST? - My Blog said, on February 28, 2012 at 11:05 AM

    [...] fits into a architectural character of a Web: REST. Some, such as Nathan Evans, go so distant as to suggest that WebSockets could shroud REST: After reading adult about a customary in fact and engaging a [...]

  17. [...] Evans,针对这一问题则表示WebSockets会使得REST相形见绌: [...]

  18. [...] WebSockets versus REST… fight! « Nathan Evans’ Nemesis of the Moment. Like this:LikeBe the first to like this post. This entry was posted in Uncategorized. Bookmark the permalink. ← Un API de manipulation de text au sein d’un éditeur de texte [...]

  19. [...] 尽管还不是官方的标准, HTML5 的使用和影响力成长迅速。 无论是 Web、移动、或甚至SOA,似乎都有一个HTML5的整合战略。然而,HTML5不仅仅是一个原有的标记语言的更新,因为它包含了其他方面如 JavaScript和WebSockets。最近我们已经听到了很多WebSockets有关的内容,包含技术的引进和是否有任何对于REST的影响。然而,近期Lori Macvittie 辩论说WebSockets可能会导致一个不太安全的网站,如果人们以安全换取性能的话。 她从2011年的一份报告指出,很多人都已经习惯于这样做,并且已经有一个调查发现了这类情况… …而91%的受访者不仅在安全性和性能之间的进行权衡,实际上整整81%是禁用安全功能的特性。 [...]

  20. [...] have bad characteristics such as high latency (round trip time) and are wasteful of battery life," according to Cambridge, UK-based developer Nathan Evans. One example Evans cites has the client petitioning the [...]

  21. northern virginia bathroom renovations said, on January 26, 2013 at 7:20 AM

    I think the admin of this web site is genuinely working
    hard in support of his web page, for the reason that here every information is quality based information.

  22. apy said, on January 26, 2013 at 11:18 AM

    I think your missing the point absolutely. Websockets work immediately over transport layer and provide full duplex; it could be better described as a session layer, HTTP is a stateless session and is a real complex protocol, with lots of non standard extensions.REST works over HTTP. So REST is obviously threaten because Websockects are elsewere: complete freedom to apps. Use HTTP/HTTPS as bootstrap and then switch to a websocket. Thats great, no stupid server-push technologies; no more dependency on request/response because both channels can request, response or even send data without being asked to. But the most two great features are: websockets throws away all the httpservlets and a lot of unrequired cpu; the second, Websockets don’t expel HTTP; they require it to bootstrap and REST services can be in the same machine next to other super efficient web socket application. HTTP to Websockets is like to switch from morse telegraph to full duplex high quality video telephony.

  23. email marketing automation said, on February 27, 2013 at 8:55 AM

    Aw, this was a really nice post. Taking a few minutes and actual effort to generate a top notch article… but
    what can I say… I put things off a lot and don’t seem to get nearly anything done.

  24. viagra said, on March 4, 2013 at 12:15 PM

    May I just say what a comfort to find an individual
    who genuinely understands what they’re talking about over the internet. You certainly know how to bring a problem to light and make it important. More and more people ought to check this out and understand this side of the story. I was surprised that you aren’t more popular because you
    most certainly possess the gift.

  25. phen375 side effects said, on March 20, 2013 at 9:18 AM

    Just want to say your article is as astonishing. The clarity for your
    put up is just nice and that i can suppose you’re an expert on this subject. Fine with your permission allow me to take hold of your RSS feed to stay updated with forthcoming post. Thanks one million and please keep up the rewarding work.

  26. Ted Hu said, on March 27, 2013 at 4:32 AM

    i don’t see why REST wouldn’t just use Websockets as another protocol. REST is a set of conventions, of which it defines 4 verbs and url-based resource naming and sub-url inheritance that are essentially object handles to data resources. HTTP runs on top of TCP/IP. Websockets could be a thin HTTP URL-based abstraction also over TCP/IP that continues to use url-based resource nouns as handles and the same set of action verbs for CRUD operations. REST is a logical request-response messaging construct that would layer fine on top of Websockets yielding extraordinary speed benefits.

  27. Anonymous said, on May 29, 2013 at 2:39 AM

    ) Long driveways and property line fences often need SCALE to
    them were hedges and colonnades could be used. Remember that there are many options open to you, all you need to
    do is use your imagination. These are derived from the colored palette of brown, green, tans, orange, white and some red.

  28. Doyle said, on June 9, 2013 at 6:26 AM

    A high fiber diet can have similar or better weight loss
    benefits without the side effects of Alli. When under
    the influence of this drug, you would eat
    less. It’s recommended that you consult your doctor before trying any diet pill.

  29. vintage pregnancy advice said, on July 11, 2013 at 11:28 AM

    The author and her husband, just like any other couples, did not prioritize having children especially at the early stage of their marriage.

    There are hundreds of success stories for this natural hemorrhoid
    cure. You can include your pregnancy test, scan photos,
    photos you take of your growing pregnancy belly as
    well as document other special memories.

  30. garden tips herbs said, on August 7, 2013 at 4:40 AM

    To be as informed as possible, read as many books, articles, and blogs on organic gardening
    as you can. Bug, insects and all sort of nasty creatures could inhabit that very soil and in turn can
    simply destroy your whole operation. A large garden may sound great, but the work involved can make it a major source of stress.

  31. Asraful Chowdhury said, on November 3, 2013 at 8:55 AM

    The article published in dec , 2011 , now at 2013 it seems REST is more popular .
    But this two concept is not competing each other rather playing as an agent in evolution of web standards for web. The example given by @Charles Wise is good one.

  32. www.xic.com said, on May 10, 2014 at 7:51 PM

    You only need to use your creativity and think out of the box.

    I would bet there is a pretty good amount that will show up in the search results.

    The advantage that you opt to get here is that you won’t have to invest in and operate
    the printing equipments.

  33. chalama said, on July 17, 2014 at 4:26 PM

    can anyone let me know how to automate websocket?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: