Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

closed as too broad by MichaelT, Ixrec, gnat, Kilian Foth, GlenH7 Feb 6 at 18:53

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Try this - – talonx Dec 5 '10 at 11:14
I find this to be informative, yet not too detailed: – NoChance 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
None of the answers below use the word "idempotent." You should look it up: idempotency is an important aspect of any RESTful architecture. – james large Jan 12 at 17:24
up vote 6 down vote accepted

What is REST (in simple English)

Plain English:

REpresentational: the action of speaking or acting on behalf of someone.
State Transfer: transfer status.


  • we do not transfer an actual object but a representation of it in a form (eg. a xml/json/text to represent a database table).
  • RESTs for exposing a public API over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.
  • REST is representes via some media type. Some examples of media types include XML, JSON, and RDF.
  • REST is an architectural style for resource-oriented architecture (ROA), not a spec or a standard.
  • Architectural style means it is a concept, theory (and how it's implemented it, it’s up to you)
  • Everything is identified by unique endpoint. i.e. There is one endpoint for each resource(data).
  • Endpoint is consist of domain name with resource address.


share|improve this answer

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

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 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 ( 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
you covered state transfer not representation. the action of speaking or acting on behalf of someone is representation how it works in this context? – Premraj Jul 2 '15 at 2:01

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 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

protected by MichaelT Jul 2 '15 at 3:47

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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