What exactly does REST mean? What is it, and why is it getting big now?

Question

I understand (I think) the basic idea behind RESTful-ness. Use HTTP methods semantically - GET gets, PUT puts, DELETE deletes, etc... Right? thought I understood the idea behind REST, but I think I'm confusing that with the details of an HTTP implementation. What is the driving idea behind rest, why is this becoming an important thing? Have people actually been using it for a long time, in a corner of the internets that my flashlight never shined upon?

---

The Google talk mentions Atom Publishing Protocols having a lot of synergy with RESTful implementations. Any thoughts on that?

Answer 1

There is a very good introduction to REST in the book RESTful Web Services by Leonard Richardson and Sam Ruby (http://oreilly.com/catalog/9780596529260/)

For the original definition of the REST architectural style see Roy Fielding's dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)

Regards, tamberg

Answer 2

Here is a google intro to REST http://googledataapis.blogspot.com/2008/10/introduction-to-rest.html

Answer 3

A good link from Wikipedia:

http://en.wikipedia.org/wiki/Representational_State_Transfer

Answer 4

REST is an architecture where resources are defined and addressed.

To understand REST best, you should look at the Resource Oriented Architecture (ROA) which gives a set of guidelines for when actually implementing the REST architecture.

REST does not need to be over HTTP, but it is the most common. REST was first created by one of the creators of HTTP though.

Answer 5

HTTP currently is under-used and mis-used.

We usually use only two methods of HTTP: GET and POST, but there are some more: DELETE, PUT, etc (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)

So if we have resources, defined by RESTful URLs (each domain object in your application has unique URL in form of http://yoursite.com/path/to/the/resource) and decent HTTP implementation, we can manipulate objects in your domain by writing sentences:

GET http://yoursite.com/path/to/the/resource

DELETE http://yoursite.com/path/to/the/resource

POST http://yoursite.com/path/to/the/resource

etc

the architecture is nice and everything.

but this is just theoretical view, real world scenarios are described in all the links posted in answers before mine.

Answer 6

Here's my view...

The attraction to making RESTful services is that rather than creating web-services with dozens of functional methods, we standardize on four methods (Create,Retrieve, Update, Destroy):

• GET
• PUT
• POST
• DELETE

REST is becoming popular because it also represents a standardization of messaging formats at the application layer. While HTTP uses the four basic verbs of REST, the common HTTP message format of HTML isn't a contract for building applications.

The best explanation I've heard is a comparison of TCP/IP to RSS.

Ethernet represents a standardization on the physical network. The Internet Protocol (IP) represents a standardization higher up the stack, and has several different flavors (TCP, UDP, etc). The introduction of the "Transmission Control Protocol" (guaranteed packet delivery) defined communication contracts that opened us up to a whole new set of services (FTP, Gopher, Telnet, HTTP) for the application layer.

In the analogy, we've adopted XML as the "Protocol", we are now beginning to standardize message formats. RSS is quickly becoming the basis for many RESTful services. Google's GData API is a RSS/ATOM variant.

The "desktop gadget" is a great realization of this hype: a simple client can consume basic web-content or complex-mashups using a common API and messaging standard.

Answer 7

This is what REST might look like:

POST /user
fname=John&lname=Doe&age=25

The server responds:

200 OK
Location: /user/123

In the future, you can then retrieve the user information:

GET /user/123

The server responds:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

To update:

PUT /user/123
fname=Johnny