REST (Representational State Transfer)

Long before SOA became a buzzword and SOAP became a necessary part of your SOA infrastructure, there was REST. And though SOAP and its other WS-* specs have stolen the limelight from this alternative service-oriented architecture, REST is gaining a lot of traction as Web 2.0 takes the Internet by storm.

REST (Representational State Transfer)--which was detailed in Roy Thomas Fielding's doctorate dissertation "Architectural Styles and the Design of Network-based Software Architectures" six years ago--can dramatically reduce the investment necessary to provide service-oriented access to enterprise resources. Fielding used the term to describe a technique and best practices for retrieving data formatted in XML over HTTP for use in applications.

Both Amazon.com and eBay use SOAP (Simple Object Access Protocol) and REST APIs, and have seen heavy use of REST since their inceptions. In fact, there are services within every organization, such as those used to access static or nearly static resources, that could benefit from REST. However, REST is based on HTTP, and so it inherits all the good and bad aspects of the protocol. It's much simpler than SOAP, but, like HTTP, it's stateless and unreliable. For critical services, SOAP has some important advantages.The Fundamentals

REST is an architectural style, not a standard or specification, built on existing, well-understood standards governed by the W3C, such as HTTP, URI (Uniform Resource Identifier) and RDF (Resource Description Format). REST services are focused on access to resources, not execution of remote services, making it a different beast than services based on SOAP. While SOAP clients request an action to be executed on the server, REST clients simply ask for a resource. Instead of requesting the remote execution of a function to find your purchase order, you'd request the purchase order, much in the same way you request a static Web page.

It's a subtle difference in theory, but a huge difference in practice in terms of the infrastructure necessary to support each service style. Technically speaking, REST services could be implemented with nothing more than static HTML pages; that's just not possible in the execution-oriented paradigm required by SOAP services.

Although it may be the case that a REST request results in the execution of remote code to create the XML that will be returned, this fact is better-hidden in REST than in its SOAP counterpart, which necessarily dictates that you specify a function to be executed. SOAP services generally (though not always) require an application server such as BEA Systems WebLogic, IBM WebSphere or Tomcat to parse the XML-encoded requests required by SOAP and to execute the appropriate code. REST services have no such requirement, as the exact resource desired is indicated by the URI. Although there may be business logic associated with a REST request that will require access to a data source or conditional logic based on query parameters, these are optional and are limited only by organizational standards, design practices and URI length limitations.The popularity of REST is no surprise, given that incorporating REST-based services into a hosted site is a simple process compared with setting up and dealing with the infrastructure and code necessary to communicate via SOAP. In 2003 Jeff Barr, Amazon.com's Web services evangelist, revealed that Amazon handles more REST than SOAP requests. And del.icio.us and Bloglines, recent entries into the super-social-networking community, also provide REST-based services and are heavily trafficked by users around the globe.

One should also consider that nearly all RSS and ATOM feeds are inherently REST services. In fact, any URI request that results in a POX (plain-old XML) response is technically a REST service, which means there are likely REST services running inside your organization right now. Go ahead and look, we'll wait.

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.

Bottom Line

There are certainly some services within every organization that can benefit from REST, while others require a solid, enterprise-class SOA infrastructure. REST is likely the best mechanism for disseminating information through RSS feeds, as well as for accessing static or nearly static resources within a SOA. For critical services, however, you'll want to stick with SOAP and the associated specifications that provide reliable messaging, security management and transactional support.

REST will continue to gain mind share and will soon be an enterprise, if not household (at least among IT folks), term. As Ajax and other Web 2.0 technologies begin to take hold in the data center, REST services will be among them as products in other SOA-minded areas begin to take note and start seriously supporting them.Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator, and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].