Thinking In REST
REST or WS-*? The debate which will never end. While REST is taking the lead gradually, the community see many drawbacks in using the traditional WS-*. The complexity and overhead in using WS-*, REST simplicity and how they fit the web architecture are always the main points of the argument. REST is simple, that is it. It has nothing to deal with except three things: Resources, Verbs and URIs. The idea of making use of the HTTP standards to accomplish all the needed CRUD operations on the resources is really interesting from the service development perspective.
It was clear from the beginning of the WS-* evolution that WS-* violates and ignores the architecture of the Web. It replaces the concept that the Web is identified by URIs to the concept that the services is identified by WS addresses. However, in the RESTful architecture, all the addressing is through URIs. This creates a homogeneous architecture comparing to how the web is actually constructed. Even dealing with URIs as your default addressing help in promoting your service in the search engines results and making it more reachable by your consumers.
WSDL doesn't give you much information about the semantic and logical interactions between the services methods. It just provide a listing for the service methods names, parameters and data types. You can't know for example what shall you need to call first to accomplish a specific task or what this service is actually doing. This is not the case in the RESTful services where you can build you own service documentation. You provide a custom HTTP GET request returning an HTML response with the allowed operations for this specific URI along with any custom documentation you may need to attach. However, you still able to describe your services using the WADL Language - the WSDL equivalent - in case you still need to use a descriptive language for your RESTful services.
Another point to mention is about how REST can make use of the HTTP protocol standards. Suppose you want to make a request to some WS-* service and get the response in several formats. You will need to pass the required response type to the service method or even make a separate method for each type! Neither of the two solutions is convenient. In REST, you can make a solid use of the standard HTTP header. You simply modify the "Accept" field in the HTTP request header with the required content-type of the response. In the server side, you will receive the required content-type in the request header so that you will be able to respond with the corresponding format. This way you save the confusion of your service consumers and make uses of the HTTP header to provide some kind of a separation between the needed request parameters and the other non-related ones.
Another point is about error handling. In REST, you are able to make use of the standard HTTP status codes in a very elegant way. You may respond with standard error 505 for example if the requested resource is not found or with error 401 if you're not authorized to access the resource. So you have a rich standard protocol to build your own services on.
RESTful architecture starts to get more and more acceptance in the web development community. Microsoft provide RESTful capabilites in its WCF Web Programming Model. Google, Yahoo, Amazon and all the big entities are now digging in the RESTful Services. There is something there you should start to care about.
3 comments:
Three points:
(1) I'd say the real problem with "WS" is a lack of interoperability. Microsoft has always shipped an "MS" stack that doesn't work with the "WS" stack on other platforms. I know a company that bet it's future on the "WS" implementation in ASP.NET and lost because it's competitor was making services that people could connect to from PHP, Cold Fusion, JSP as well as ASP.NET.
(2) Most people don't really mean "REST" when they say "REST". Technically, "REST" means that you use the GET, PUT and DELETE operations in a certain way. Most Open Web Services use GET and POST operations much like a browser filling out a web form and return results in XML or another format. People call this "Plain Old XML" or POX. If you need something that's a little better at handling structured data in the request, nothing is stopping you from POSTing XML in the request body.
(3) Don't forget XML-RPC. People were using XML-RPC to build real applications back when people were just talking about SOAP. XML-RPC doesn't have corporate 'support', but it's had interoperable implementations for both major and minor web platforms for half a decade.
The reason REST is currently "simple" is that solutions to the hard problems do not exist. If you think REST is simple, here's a simple problem for you: create a RESTful way for competing consumers to dequeue a message from a queue that guarantees only one consumer owns it.
Here's the solution:
http://activemq.apache.org/restful-queue.html
http://tech.groups.yahoo.com/group/rest-discuss/message/8955
This is NOT simple!
@bwtaylor: Actually, you're talking about the complexity of the application not the technique itself. Simple here means that REST is more simple than WS-* as technique for building services. I am not talking about how the applications are simple or not. For the proposed queue application you pointed out later, you would face the same complexity if you are using WS-*. Still it's about the complexity of the application, not the complexity of REST itself.
Post a Comment