Web services beyond REST

I think that anyone who has feelings about the REST and web services (indeed if you understand anything of either) should immediately read this piece, “Web Services: REST in Peace?”, by Jim Webber. He makes the argument that the prejudices in favor of REST stem from the early days of web services when indeed they were little more than XML based RPC. We’ve come a long way since then, in his opinion to the point that web services has surpassed REST.

This seems to stem from the fact that SOAP is now the lowest level protocol in a web services stack, so there is no longer a dependency on an application protocol like HTTP. While HTTP is perfectly well suited to REST and web services REST does require certain properties of any protocol that it lays on top of and today HTTP is really the only game in town. Web services by comparison can use SMTP, JMS and yes, even UDP. Another excellent point he makes is that in preparing a REST based application you have to through a process of resource modeling to map the semantics of you application to RESTful presentations, typically only using the HTTP verbs GET, POST, PUT and DELETE. However web services force you into no such conundrum. Here I think is one of his best points though on how web services enforce a certain correct view of a distributed system.

From the point of view of a consumer, binding directly to a Web Service, increases the danger that we begin to view services as objects. This is a mistake treating the exchange of messages with a service as being equivalent to a local object invocation is inherently incorrect. However, if our implementations bind to the messages that a service exchanges, we are always bound to local objects (in fact the objectified versions of the messages) and can treat them as such without danger. Additionally, since crossing service boundaries is made explicit by the sending of messages, it reinforces the fact, in architecture and code alike, that inter-component communications is between remote, autonomous entities.

Now on to some of my own points, specifically about the article Real Web Services with REST and ICF by https://weblogs.sdn.sap.com/pub/u/3294[original link is broken][original link is broken][original link is broken][original link is broken][original link is broken][original link is broken] (who will be missed). I’ve meant to file a proper report on this for so long, but I have finally realized I work better (or at least quicker) in blog form.

First off I think many of the points regarding the proper view of protocols is already addressed above. To some of the points that SOAP does not address the data and that somehow the resource view is more appropriate and makes the data more accessible I must simply disagree. The fact is that there is much wishful thinking in the REST based view of the world about content negotiation. While I agree you can determine what forms of data a client can accept how do you describe what you are providing? To me this is one of the largest gaps in a pure RESTful view of things. I’m not aware of any RESTful toolset that allows you to point at a RESTful endpoint and generate proxies for what is provided that you can introspect and use in code. Or am I missing something? Additionally there is simply no capabilities for discovery at all. From a security perspective I think there is a good argument for similar capabilities, but from a policy perspective again the edge goes to web services.

One thing I found particularly incorrect was the viewpoint that web services simply hide themselves over HTTP port 80 and make a firewall administrator’s life hell. This is utter nonsense. First off any firewall worth its salt can filter traffic within port 80, its not a free for all. Ask any corporate end user who hasn’t been able to get the HTTP tunneling for an IM client (typically shut down for security reasons) or media player (shutdown due to bandwidth issues) to work. How is asking someone to inspect URLs to decide what to do with them, especially when there is no associated policy or description of what these represent, any better? In fact the SOAP header construct can specifically address intermediaries to more intelligently route through these systems according to a managed corporate policy. There are lots of products out there that specifically address these needs.

1 Comment

I think the point that you must concede to the proponents of the REST pattern is that it captures the way the Web works. RPC is not how the Web works, nor is message-passing. Sure, it’s legitimate to do RPC and/or message-passing using the same infrastructure and open standards that are the basis of the Web, but calling it Web Services is kind of a misnomer — in particular because it is indeed more general than the resource-oriented REST approach.

Interesting that RPC-style SOAP is now considered the “old Web Services” and message passing the “new (right) Web Services”. Did we get it the other way round at SAP? XI with its messaging approach, which came first, is now being “integrated” into the WS infrastructure [ESI] (and I bet we’ll see a lot of RPC-style services in the future).

Frankly, I don’t think that the difference between RPC and messaging is essential. Both paradigms allow for both sensible and absurd designs. The question is, will WS eventually be a greater success than CORBA? “End of 2004” is too early to judge.