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.