加载中

For the past few years WebSockets has been gaining in popularity and availability. At the end of last year it moved one step closer to a standard by becoming a W3C Candidate Recommendation. Oracle and others have also recently submitted a request to start a standardisation effort around WebSockets (JSR 356) in the next version of Java Enterprise Edition. All of the major browsers, such as Chrome, Firefox, Safari and IE, support one of the WebSockets revisions and will ultimately adopt whatever the standard eventually becomes. In a relatively short period of time, WebSockets has almost become an integral part of the Web. However, there remains a segment of developers who are uncertain as to how or whether WebSockets fits into the architectural style of the Web: REST. Some, such as Nathan Evans, go so far as to suggest that WebSockets could overshadow REST:

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.

过去的几年,WebSockes逐渐成熟并变得可用,去年年底,它距离成为标准更近了一步:成为了W3C CR。Oracle和其他一些组织最近也提交了关于在下个版本的Java EE中启动WebSockets标准化的请求。所有的主流浏览器如Chrome,FireFox,Safari和IE都支持众多WebSockets版本中的一种,但如果标准一旦制定,无论如何他们也将最终遵循制定的标准。在一个相对较短的时间里,WebSockes几乎已经成了Web不可分割的一部分。然而,仍然有部分开发者不确定WebSockes是否或者适应Web的架构风格:REST。他们中的一些,例如Nathan Evans就比较激进,他认为WebSockets可能给REST蒙上阴影。

在详细阅读了标准以及吸收了一些网上围绕此话题展开的讨论之后,我日益认为这份标准将占有RESTful服务的大量思想。我的意思是说,未来某个时间在产品开发时将会有人问到:

"好吧兄弟们,这个产品中我们到底是用WebSockets呢还是REST?"

我期望在一两年内 WebSockets将开始阻止RESTful Web服务的发展,至少如我们现在所知的那样。
In his article Nathan believes that based on his experiences of using REST, it is not the "silver bullet" that some other people portray it as, although he admits that WebSockets is also not perfect. He then outlines a number of reasons why WebSockets is a threat to REST, including "sub-par" REST frameworks reliance on text-based protocols. Some of the important benefits that WebSockets offers over REST include bi-directional interactions:

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.

在他的文章中,Nathan认为尽管他承认WebSockets并非完美,但基于他使用REST的经验,REST也不是他人所描述的银弹。然后他列出了WebSockets为何会成为REST的威胁的几条理由,包括“不够格”的REST框架依赖基于文本协议的情况。还有一些相比REST,WebSockets提供的重要好处,比如双向交互的能力。

WebSockets提供的真正的双工通信是任何其他HTTP传输的协议所不具备的,无论它是SOAP还是REST。而Comet,Push和长轮询也只能模拟,还非常低效。双工通信天性就足够好滴允许你建立实时TCP通讯协议,比如RDP或VNC。
Nathan believes that the benefits of WebSockets outweigh those of REST (HTTP) and that developers will migrate towards WebSockets in preference to it.

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. [...] 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.

Nathan相信WebSockets提供的好处比REST(HTTP)更有用,所以开发者们将会喜欢WebSockets而转向使用它。

REST可能仍将是需要可视性和跨平台互操作性的项目的首选。然而不需要这些特性的项目将很可能选取WebSockets,在其上仍可使用JSON,或 一种预定的通讯协议。尽管他们是竞争者的关系,他们仍可共存.事实上,他们其实是相辅相成的,因为他们都是建立在HTTP基础之上。 
However, Nathan isn't the only one to raise the question of "WebSockets or/versus REST". For instance, Shay Bannon wondered in 2010 whether it is even possible to use the principles of REST with WebSockets:

First and foremost, how do you represent a URI? Second, how do you represent the HTTP methods (GET, PUT, POST, …)? And last, how do you represent HTTP uri parameters and headers? It seems like maybe a solution for this is to built some sort of schema into the content that goes into that text string. Something like a JSON string that has a “uri” field, and “params” and so on. But thats annoying, since with HTTP, you can create very simple gateways that simply use the headers or parameters without needing to parse the body…

然而,Nathan并非提出"WebSockets or/versus REST"这一问题的唯一一人。例如Shay Bannon在2010年曾提出是否可以在WebSockets中使用REST的原则的一些问题。

首要的是,如何表示一个URL?其次,你如何表示一个HTTP方法?最后,你如何表示HTTP URL参数和HTTP头?看起来一种解决办法是在让内容文本遵循一种规则,就像JSON字符串那样,具有一个URL字段和参数字段等等。但这也是很恼人的,因为在HTTP中,你可以直接使用HTTP头或者参数来很简单地创建连接,而不需要解析内容。
He wonders why WebSockets does not have notion of URI or header, and as a result whether there is a need for a REST-over-WebSockets specification before people reinvent REST and end up doing so "not in a uniform manner"? At the time he received a mixed response to this article. For instance one respondant, who mentioned he worked for a WebSockets company, so perhaps not too objective, stated:

REST and WebSocket communication seems to be two different types of distributed computing plumbing. REST is the old-school, sit on top of HTTP, synchronous style of web rpc. WebSocket is the newer, sit along side HTTP, usually asynchronous style of web communication. Imho, in the long term, WebSocket will dramatically reduce the need for REST for WAN computing. With WebSocket, all the protocols we've known and loved for the past few decades can now be extended over the web without the clumsy and performance-sucking mapping to HTTP.

 And another:

My take is REST involves the conventional request/response paradigm. In contrast sockets cater for the comet/long polling scenario where the line of communication stays open for several communication cycles. Also, the initial handshake to WS still occurs from HTTP, so in reality they are not mutually exclusive. I also thought the whole point of the WS protocol was to get rid of the cruft in the HTTP Headers as it becomes redundant and just adds to the payload size.

他觉得为何WebSockets就没有“URI”或“头”的概念,因此是否需要一种REST-over-WebSockets的规范,以防止人们重新发明REST并最终导致“各行其道”?那时他的文章收到了各种答复,比如一个答复者说他在一个WebSockets公司工作,所以他的观点可能不是客观的,他提到:

REST和WebSocket的通讯看起来是分布式计算管道的两种类型。REST是那个老学校,坐在HTTP的顶上,同步风格的web调用。WebSocket是新的,坐在HTTP旁边的,通常是异步的web通信。恕我直言,长期看来,WebSocket将显著地降低WAN计算中对于REST的需求。使用WebSocket,过去几十年中我们所熟知和喜爱的所有协议将被扩展,并且不会出现在使用HTTP的情况下的笨拙和低效。

还有另外一个提到:

我认为REST陷入了传统的请求/响应模式。而WebSocket满足了Comet和长轮询的场景,通讯管道在多次通讯过程中并不关闭。同时,到WS初始的握手仍然由HTTP发起,所以实际上他们并非互斥的。我还认为WS协议的目的就在于摆脱HTTP头中那些令人讨厌的东西,因为它们冗长并且只增加了负载。
However, while agreeing that REST and WebSockets can and should co-exist, several commenters disagreed with the notion of a REST-over-WebSockets specification at all, with one adding:

if you consider REST in the Fielding sense, with a web of addressable objects (or resources), then that doesn't really work in a duplex comms format. You don't expect the resources to initiate the conversation. WebSockets will transform the web (if they take off), but not as a protocol for REST-style communications.

 And another giving a more detailed point of view:

WebSockets are like a conversation between two people with ADD. It's full duplex, so both sides can talk at the same time, and both sides have to keep their listening caps on *while* they're talking. REST is stateless and synchronous, dealing only with request->response. You would have to expand the concept of REST to get the benefit of unprompted server->client communication. I could see there being a library that implements REST in WebSockets, but it would only be useful for applications that already have a RESTful API and want to get the benefit of reduced overhead that a single connection would afford without refactoring their code.

然而,在同意REST和WebSockets能并且应该共存的同时,一些评论者完全不同意REST-over-WebSockets规范的概念。一个说道:

如果你把REST看作字段式的,具有地址的资源,那么这在双向通讯中无法工作。你无法期待资源会初始化对话,WebSocket会改变Web,但不是作为一个REST风格的通信协议。

而另一个更详细地描述了自己的观点:

WebSockets就像两个人的对话,是完全双工的,因此双方都可以同时说话,而且双方在说话的时候也都必须同时保持监听。REST是无状态和同步的,只能处理请求->响应。要获得自发的服务器向客户端的通信,你必须扩展REST的概念。我看到过一个使用WebSocket实现了REST的库,但它也只能对于那些已经有了RESTful API并且想要获得低开支的好处,以使单个连接即可满足通信要求而不用重构代码的应用有好处。
Then there are some in the REST community, such as Jim Webber, who believe that WebSockets are not right for the Web:

Jim Webber tweet

With WebSockets almost at the point of becoming a standard, as well as being supported and used in browsers, mobile and in the cloud, it is interesting to wonder how much of an impact they will have on developers who are currently using REST and HTTP, or do they address a different developer segment? Worse still, are we at risk as some believe, of "breaking the Web"?

REST社区也有一些人,比如 Jim Webber,认为WebSockets 对web来说不是好的选择

Jim Webber tweet

在WebSockets即将成为标准之际,它正在被广泛支持并使用于浏览器、手机,想要弄清楚它们对正在使用REST和HTTP的开发者会产生多大的影响是很有趣的,亦或它们针对的是不同的开发者团体?更糟的是,一些人相信我们正在冒着“破坏Web网络”的危险?

返回顶部
顶部
返回顶部
顶部