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.
OK, I’m done. I feel better.
Before I go I just have to point to Mark Baker‘s (a noted RESTifarian) post in which he predicted that “web services will be considered an utter failure by the industry by the end of 2004”. I actually searched for a refutation of this statement, but oddly enough he just reiterated it about 10 minutes ago. He may try at some point to claim he was right as he qualified the prediction with the argument that web service proponents would absorb REST. Microsoft recently published WS-Transfer (pdf) that maps the RESTful HTTP verbs to SOAP which he could use for that argument, but personally I think it’s a rather marginal spec that won’t gain wide traction among the current web services crowd. Instead I think it just might get the current REST crowd onto the web services bandwagon instead.