What are the benefits and limitations of building services with REST?
REST stands for Representational State Transfer, 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 anathama 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.
Dig Deeper on Topics Archive
Related Q&A from David Chappell
In this expert response, David Chappell discusses how much middleware latency is too much. Continue Reading