Mark Nottingham highlights the use of the term ‘REST’ by the Microsoft robotics folks. I also think that there is a suggestion in Mark‘s post about Windows Communication Foundation (WCF, used to be known as Indigo) not necessarily being a good fit for RESTful applications.
As I have said many times in the past, Web Services is a suite of technologies that could be used to build applications according to any of the architectural models that are out there. The WSRF folks have done a great job at showing how one could build distributed object-based applications, the WS-Transfer folks have shown how one could build CRUD-like applications, the MEST folks (well, Jim and I) have been talking about message-oriented solutions, etc. WCF is a messaging infrastructure which can be used to support all architectural styles. It’s no surprise that there are folks who use it in a RESTful way (e.g. the robotics application model, the RSS/Atom toolkit, the POX example, etc.).
Also, the robotics team is not the only one thinking about REST, the Web, HTTP, etc. 😉 I can’t wait until the time comes to start blogging about what we are up to with Don and the rest of the gang.
4 responses to “REST and the Robotics Application Model”
Repurposing SOAP toolkits for doing HTTP is like using a hammer to eat your dinner. They do different things. They are different things.
This is why I’m so against using WSDL for describing plain HTTP. It’s not meant to do that; it’s not optimised for it, and it’s built with different assumptions in mind. Wrong tool.
I find it very difficult to see most vendor (and not just Microsoft) forays into serving the REST/HTTP/POX crowd as anything but an attempt to opportunistically repurpose their investment in SOAP and WSDL.
Doing so doesn’t serve your customers well, when the practical focus of their REST/HTTP efforts is using existing, widely-deployed and simple technologies interoperably, with a low barrier to entry. SOAP doesn’t meet most of those criteria, and by making the transition from HTTP to SOAP so seamless, they’ll be constantly tempted to do “just a little more”, which will translate to lock-in.
I’m not saying that this is intentional or evil; it’s just how vendors think; it’s like breathing to them.
Totally agree with Mark. It’s more difficult to use a general framework in a specific way, than it is to use a specific framework. I think that’s the fourth law of thermodynamics or something … 😎
Hum… now that I work for Microsoft am I allowed to agree with Mark? I need to check my contract…
Like you, I too am a believer in using the right tool for the right job. If WCF or any other middleware platform does not meet one’s application’s needs, then other solutions should be considered. In a recent Web-related prototype I built, I used System.Net.WebRequest/WebResponse to play directly with HTTP headers. However, most developers/customers are not like you and me. They like the convenience of DataContract, they like messages abstractions and class decorations (some times at the cost of functionality flexibility but always taking into account the development times and software maintainance).
The real point i was trying to make thought (obviously not very well) was that REST should not be coupled with any middleware platform (like WCF) or suite of technologies (like Web Services or HTTP). You guys know that much better than I do.