Randy Ray of Tellme Networks, Inc. is giving a talk called "Don't Drop the SOAP." His basic thesis is that Web services require complexity. Ray says that there's nothing wrong with having simpler protocols, only in assuming that they replace more complex ones. In the intro to REST and SOAP, Ray discusses some of the big adopters. Interestingly, for REST he lists Amazon and Google, while for SOAP he lists .Net and Axis. Toolkits are not the same as users.
He begins by trying to counter some of the arguments RESTians make against SOAP. I'm not sure he made many points. I didn't find the arguments all that credible. He would have been better off, I think, in skipping this and making his main point: some things require SOAPs complexity.
A detour: Ray offers XML-RPC is a middle road that is simpler than SOAP and handles structured data better than REST. There are over 80 implementations in over 30 languages for XML-RPC. Pretty good coverage.
Don't confuse complexity and detail. Amazon returns a lot of data, but that doesn't make it complex. Amazon has a simple interface since the URI really comes down to the ASIN, the key for the data related a any given product.
On the other hand, complex services like MapPoint.Net has simple interface hooks that don't return a lot of data, bu rather need significant data as input.
Sending data in a URI is a limited solution. How do you represent structured data. Its easier to express simple data in SOAP than to represent complex data in REST.
Ray uses an example from TellMe to show a place where REST doesn't work as well as SOAP: TellMe moved from the MapPoint v1 (REST) API to the MapPoint v3 API. The fact that it was a .Net interface forced Ray into a .Net implementation. Nevertheless, even had that not been the case, the message you send to MapPoint is complicated with lots of data, including a result mask.
That's not the end however, the CalculateRoute API allows not just a start and end point, but also an arbitrary number of waypoints along the way (to calculate the route for an entire trip).
Since this is a constant resource--the route won't change (much)--this should be a GET request with a URL. Designing such a GET request is difficult. There's no real standard for creating a REST protocol. There's no WSDL.
That's just the first half of the equation. You still need to process the results. REST doesn't define a vocabulary for the response. The fact that REST content varies from service to service makes this part hard to standardize as the request side of the system.
In summary, I think Ray made a few good points, but his argument was weak. There's certainly services, particularly those designed to work with .Net, that will be difficult to build as a RESTful service. Still, the dichotomy between big users, on one hand, and toolsets, on the other, pointed out in the first paragraph show, I think where the momentum lies. Ray's slides are available.
