Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Lately I have become interested in familiarizing myself with REST. I tried reading wiki entry on REST, but it was of no help. I would really appreciate it if someone can explain in simple English (that is without unnecessary tech jargon)

  1. What is REST
  2. What position it occupies in web architecture ecosystem
  3. How tightly (or loosely) it is coupled with protocol.
  4. What are the alternatives to REST and how does REST compare with them.

I understand it may not be possible to answer this in one or two paragraphs, in that case relevant links will be highly appreciated.

share|improve this question
Try this - tomayko.com/writings/rest-to-my-wife –  talonx Dec 5 '10 at 11:14
I find this to be informative, yet not too detailed: ibm.com/developerworks/webservices/library/ws-restful –  Emmad Kareem Apr 18 '12 at 1:07
I wonder if this questions can be considered answered? –  Gary Rowe Jul 29 '13 at 15:34
@GaryRowe I had marked one answer, guess it was removed for some reason. I don't understand this site. –  Gaurav Aug 1 '13 at 9:57
@Gaurav Yeah, answers seem to come and go. It's all a bit odd really. –  Gary Rowe Aug 1 '13 at 19:09

4 Answers 4

What is REST?

REpresentational State Transfer. It describes how one system can communicate state with another. One example would be the state of a product (its name, description etc) represented as XML, JSON, or plain text. The generalised idea of state is termed a resource.

What position does it occupy in a web architecture ecosystem?

REST is commonly associated with the web services interface since HTTP is by far the most common carrier protocol. In the 7-layer model it exists at the application layer. However, see the next section.

How tightly (or loosely) it is coupled with protocol?

REST is not HTTP. It uses HTTP because in its most general form REST exists to assist a machine in mapping the concept of a verb against an arbitrary collection of nouns. HTTP contains a useful set of generic verbs (GET, PUT, PATCH etc) that can applied to arbitrary nouns expresssed as URIs using HTTP e.g. GET http://example.org/Product(54).

What are the alternatives to REST and how does REST compare with them

This is akin to asking "How RESTful is my approach?" Use the following list (summarised from the Richardson Maturity Model as described by Martin Fowler):

Level 0 - The swamp of POX

Use POST for everything (reads, writes, deletes). This is SOAP, POX, RPI etc. You're just using HTTP as a tunnel for your own protocol. You target a single endpoint that does everything based on the contents of the request body.

Level 1 - Resources

Use POST for everything. Target multiple endpoints designed to serve up information about a particular thing. You've just discovered resources.

Level 2 - HTTP verbs

Use HTTP verbs against resources. Now you're GETing it. POST is to create, PUT is to overwrite, OPTIONS for available operations, DELETE to, well, delete the resource. As a result of the use of these verbs different HTTP status codes start to become more relevant (202 ACCEPTED anyone?).

Level 3 - Hypermedia control (HATEOAS)

At this point you make the final leap and introduce hypermedia as a flow control mechanism. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. This can be communicated in HTTP through the Content-Type header field. Text formats include AtomPub and (more concise) HAL, while HyperAudio works well for audio streams (see SoundCloud et al)

share|improve this answer
you say "REST is not HTTP", but Roy Fielding seems pretty fixated on the idea that hypertext is a requirement, what with the whole HATEOAS deal without which -- according to him -- you aren't doing "proper" REST. While hypertext != HTTP, I wonder how much you can actually do outside HTTP... –  Andres F. Apr 23 '12 at 17:28
According to this (roy.gbiv.com/untangled/2008/…) Roy Fielding makes the point that hypertext, or its subset, hypermedia, can be expressed outside of HTML just so long as it supports linking of some kind. –  Gary Rowe Apr 23 '12 at 19:47
HTTP works well with REST because it offers standardised verbs for working with URIs that represent nouns in REST in a stateless protocol. Ideal. However in his dissertation (ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) he notes that "REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components." Thus a full FTP implementation is unlikely to be RESTful without client-side state management. –  Gary Rowe Apr 23 '12 at 19:54
+1 for the Martin Fowler link. As usual Martin Fowler has written an article that describes a concept in the most clear and concise possible way –  Tom Carter Apr 24 '12 at 9:33

While REST is an abbreviation of Representational State Transfer, it may be easier to consider the idea of performing various actions through a somewhat intuitive interface.

For example, a URL such as http://www.mysite.com/FindProduct/125/ could be interpreted as someone wanting to information on the product with an id of 125.

While REST is usually thought of in terms of HTTP, the concept could be applied to other protocols as noted in the Wikipedia reference.

Other examples of REST that may be useful:

share|improve this answer
Thanks for the link to "Learn REST: A Tutorial"! That's the first tutorial I've read that leaves me with the feeling I've learned something concrete. Everything else I've read (including the Wikipedia article) describe REST in only the most abstract ways, surrounded by technical jargon. –  Avian00 Jul 9 '13 at 9:08

I was going to reply and then I saw talonx's url so:

I will just add that the alternative is using something like SOAP (there are others) which allows the developer to create his own API calls and simply define them in XML (or json or whatever) so that the client machine knows how to use it (as long as the machine also knows how to parse the xml or json or whatever document that explains it). This is more custom and allows you to create your own "verbs" also more secure since usually data is encrypted.

REST is already defined and universal since it's basically how the HTTP protocol works and so a website that complies with that is called RESTfull. I actually learned more about it by following the URL that talonx provided :).

share|improve this answer

Using traditional soap webservices allows you to define a complex method signature in the wsdl.

Using rest you are restricted to using different urls and request methods (post, put,delete, and get) for different functionality.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.