Representational State Transfer (REST)

What is REST?

REST is an architectural style. It is not a standard. Compliance with SOAP and WSDL is the comparing of messages and documents against a detailed specification, a REST web service is more of a way thinking. REST models application-to-application service calls around the way the web works already, while SOAP/WSDL use the web as a way to perform remote procedure calls.

Defining a REST Web Service

• The service is fundamentally built around the concept of resources rather than the concept of remote procedure calls as SOAP/WSDL is. A REST-style web service fetches, modifies, creates, and deletes resources, while a SOAP/WSDL web service exposes remote procedure calls that may (or may not) act upon resources in the same way.
  
• The resources that a service returns are identified and fetched using a URI. Fetching a resource should be side-effect-free.
  
• The services application is prepared for mechanisms such as proxy servers, caches, and security mechanisms that may live between the provider and the end consumer.
  
• The resources reference other resources using URI hyperlinks, just as HTML documents do.

The purpose of many web services is to allow the consumer to perform some action on the server. A Web service can allow the consumer application to make a purchase. The REST approach dictates that in reality you are creating a new resource, a purchase order. Part of creating the new purchase order resource is that the purchase is processed, a charge is made against the customer's account or credit card, an item is taken out of inventory, the accounting system is updated, instructions are sent to pack and ship the item, and so on. The response to the purchase request would be a URI that points to the purchase order. As the purchase proceeds, the consumer can check the purchase order to see what the state the purchase is in-for example, whether the item has shipped.

The REST approach is simple and closely mirrors the workings of the traditional web. It is successful even though it is often overshadowed by SOAP/WSDL. For instance, Amazon, which offers both a REST interface and a SOAP/WSDL interface, has reported that the REST interface is more popular.

Within a REST service, the consumer deals with XML directly. This is a pro and a con at the same time.

In comparison with SOAP/WSDL, REST suffers most significantly in platform support. Both J2EE and .NET have embraced SOAP/WSDL. You can certainly put together REST-style web services on the J2EE and .NET platforms, but both platforms have made it much easier to put together SOAP/WSDL web services. REST is the resource-oriented or document-oriented approach, and SOAP/WSDL is the remote procedure call approach.

Pros and Cons

Proponents of REST services claim they are more scalable and therefore better able to handle high-volume services. SOAP services are inherently more compute-intensive because they must parse XML and serialize objects--operations that require specialized software/ hardware to optimize manage and accelerate.

REST services are simple HTTP requests, meaning they can be easily load-balanced and managed using conventional Layer 7 traffic-management devices, such as those from Cisco Systems, Citrix and F5 Networks. Monitoring REST-service usage is also much simpler and often less expensive since URI-based monitoring is an established technology with both open-source and commercial solutions available.

REST-based services are easier to implement because they are founded on well-known Web protocols and don't require developers to learn WSDL, SOAP and the plethora of WS-* specifications used to manage and secure SOAP-based services. The simplest of REST-based services can be implemented in minutes--a static XML file returned by a Web service is, technically, a REST service because a request for XML data over HTTP has been fulfilled. Although not likely the best option for building out your service infrastructure, for static resources or rarely changing resources, such an option is attractive.

All is not perfect in REST land, though. Because REST is based on HTTP, it carries that protocol's stateless and unreliable nature. That's where those complex WS-* specs come in handy. Security, reliable messaging and transaction support are just a few of the enterprise-class needs addressed by OASIS' WS-* specs--and something you won't find for REST no matter how hard you look.

REST also doesn't provide a standardized mechanism for accessing resources, so you must define the standards and enforce them, as well as communicate the means by which services will be accessed to partners, developers and users. And you must keep that communications mechanism up to date in case of any changes to the service. In the SOAP world, WSDL performs this task for you, acting as a dynamic contract between the service and its clients.

For more information on REST, just continue and click here.