Can you explain the Web concept of RESTful?

Question

A RESTful application is an application that exposes its state and functionality as a set of resources that the clients can manipulate and conforms to a certain set of principles:

• All resources are uniquely addressable, usually through URIs; other addressing can also be used, though.
• All resources can be manipulated through a constrained set of well-known actions, usually CRUD (create, read, update, delete), represented most often through the HTTP's POST, GET, PUT and DELETE; it can be a different set or a subset though - for example, some implementations limit that set to read and modify only (GET and PUT) for example
• The data for all resources is transferred through any of a constrained number of well-known representations, usually HTML, XML or JSON;
• The communication between the client and the application is performed over a stateless protocol that allows for multiple layered intermediaries that can reroute and cache the requests and response packets transparently for the client and the application.

The Wikipedia article pointed by Tim Scott gives more details about the origin of REST, detailed principles, examples and so on.

The best explanation I found is in this REST tutorial.

REST by way of an example:

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

Frankly, the answer depends on context. REST and RESTful have meanings depending on what language or framework you're using or what you're trying to accomplish. Since you've tagged your question under "web services" I'll answer in the context of RESTful web services, which is still a broad category.

RESTful web services can mean anything from a strict REST interpretation, where all actions are done in a strict "RESTful" manner, to a protocol that is plain XML, meaning its not SOAP or XMLRPC. In the latter case, this is a misnomer: such a REST protocol is really a "plain old XML" (or "POX") protocol. While REST protocols usually use XML and as such are POX protocols, this doesn't necessarily have to be the case, and the inverse is not true (a just because a protocol uses XML doesn't make it RESTful).

Without further ado, a truly RESTful API consists of actions taken on objects, represented by the HTTP method used and the URL of that object. The actions are about the data and not about what the method does. For example, CRUD actions (create, read, update, and delete) can map to a certain set of URLs and actions. Lets say you are interacting with a photo API.

• To create a photo, you'd send data via a POST request to /photos. It would let you know where the photo is via the Location header, e.g. /photos/12345
• To view a photo, you'd use GET /photos/12345
• To update a photo, you'd send data via a PUT request to /photos/12345.
• To delete a photo, you'd use DELETE /photos/12345
• To get a list of photos, you'd use GET /photos.

Other actions might be implemented, like the ability to copy photos via a COPY request.

In this way, the HTTP method you're using maps directly to the intent of your call, instead of sending the action you wish to take as part of the API. To contrast, a non-RESTful API might use many more URLs and only use the GET and POST actions. So, in this example, you might see:

• To create a photo, send a POST to /photos/create
• To view a photo, send a GET to /photos/view/12345
• To update a photo, send a POST to /photos/update/12345
• To delete a photo, send a GET to /photos/delete/12345
• To get a list of photos, send a GET to /photos/list

You'll note how in this case the URLs are different and the methods are chosen only out of technical necessity: to send data, you must use a POST, while all other requests use GET.

Just a few points:

• RESTFul doesn't depend on the framework you use. It depends on the architectural style it describes. If you don't follow the constraints, you're not RESTful. The constraints are defined in half a page of Chapter 5 of Roy Fielding's document, I encourage you to go and read it.
• The identifier is opaque and does not cary any information beyond the identification of a resource. It's a nmae, not input data, just names. as far as the client is concerned, it has no logic or value beyond knowing how to build querystrings from a form tag. If your client builds its own URIs using a schema you've decided up-front, you're not restful.
• The use or not use of all the http verbs is not really the constraint, and it's perfectly acceptable to design an architecture that only supports POST.
• Caching, high decoupling, lack of session state and layered architecture are the points few talk about but the most important to the success of a RESTful architecture.

If you don't spend most of your time crafting your document format, you're probably not doing REST.

It means using names to identify both commands and parameters.

Instead of names being mere handles or monikers, the name itself contains information. Specifically, information about what is being requested, parameters for the request, etc..

Names are not "roots" but rather actions plus input data.

I've learned the most from reading the articles published on InfoQ.com: http://www.infoq.com/rest and the RESTful Web Services book (http://oreilly.com/catalog/9780596529260/).

./alex

Disclaimer: I am associated with InfoQ.com, but this recommendation is based on my own learning experience.