What are the benefits and limitations of building services with REST?
REST stands for Representational State Transfer (see quote below), and places the emphasis on using a representation of a resource (the thing a URL points to) to hold the state of an application. The emphasis REST places on state being held in the representation places it in direct opposition to most web development frameworks: things like cookies and server-side sessions are anathema to REST applications, for example. That being said, the TAG within the W3C is investigating the idea of state in web applications, and there is definitely a REST contingent that thinks cookies have their place. Generally speaking there are debates about how state can be handled well in practical applications using REST, but conventions and communal wisdom haven’t yet emerged.
A good REST application uses a small number of verbs, and typically, sophisticated representations (XML being an obvious one). A good REST application will exhibit key network features such as transparent cachability, which can lead to improved performance is widely distributed systems, scalability, reduced server load, statelessness on the server making failover easy, etc. etc. Sophisticated REST applications require careful design in order to make them stateless, which still preserving application semantics, security etc.
REST does not prescribe the HTTP verbs, but you can build REST applications using HTTP if you are careful (avoid cookies and server side state). At this point, a good use of REST in a SOA world would be for simple services, such as a transformation service, PO submission service, etc. where caching, scalability etc. are all acceptable.
REpresentational State Transfer
REST (REpresentational State Transfer) is a simple stateless architecture that generally runs over HTTP.
REST involves reading a designated Web page that contains an XML file. The XML file describes and includes the desired content.
REST is often used in mobile applications, social networking Web sites, mashup tools and automated business processes. The REST style emphasizes that interactions between clients and services is enhanced by having a limited number of operations (verbs). Flexibility is provided by assigning resources (nouns) their own unique universal resource indicators (URIs). Because each verb has a specific meaning (GET, POST, PUT and DELETE), REST avoids ambiguity.
As described in a dissertation by Roy Fielding, REST is an “architectural style” that basically exploits the existing technology and protocols of the Web, including HTTP (Hypertext Transfer Protocol) and XML. REST is simpler to use than the well-known SOAP (Simple Object Access Protocol) approach, which requires writing or using a provided server program (to serve data) and a client program (to request data).
XML and JSON
Favor JSON support, but unless the costs of offering both JSON and XML are staggering, offer them both. Ideally, let consumers switch between them by just changing an extension from .xml to .json. In addition, for supporting AJAX-style user interfaces, a wrapped response is very helpful. Provide a wrapped response, either by default or for separate extensions, such as .wjson and .wxml to indicate the client is requesting a wrapped JSON or XML response.
JSON in regards to a “standard” has very few requirements. And those requirements are only syntactical in nature, not about content format or layout. In other words, the JSON response to a REST service call is very much part of the contract—not described in a standard. More about the JSON data format can be found at http://www.json.org/.
Regarding XML use in REST services, XML standards and conventions are really not in play other than to utilize syntactically correct tags and text. In particular, namespaces are not, nor should they be use in a RESTful service context. XML that is returned is more JSON like—simple and easy to read, without the schema and namespace details present—just data and links. If it ends up being more complex than this, see the first paragraph for this tip—the cost of XML will be staggering. In our experience nobody uses the XML responses anyway. It’s just too expensive to process.
Even more resources:
Note: some of the links above may have deprecated content which does not apply anymore (in 2013), however they are useful for a better understanding of RESTful techniques.
Once a week or so we send an email with our best content. We never bug you, we just send you our latest piece of content.
If you found any value in this post, agree, disagree, or have anything to add - please do. I use comments as my #1 signal for what to write about. Read our comment policy before commenting! Comments such as "Thank you!", "Awesome!", "You're the man!" are either marked as spam or stripped from URL.