RESTRepresentational State Transfer

REST is centered on two main principles for generalized network design:

• Resources are represented by URLs A resource can be thought of as a "noun" and refers to some entity we want to deal with in the API of a web service; this could be a document, a person, a meeting, a location, and so on. Each resource in a REST application has a unique URL.

• Operations are carried out via standard HTTP methods HTTP methods such as GET, POST, PUT, and DELETE are used to carry out operations on resources. In this way we can consider such operations as "verbs" acting on resources.

A Hypothetical REST Example

To understand how and why we might apply these ideas, let's look at a hypothetical example.

Suppose that we have a web service that allows writers to submit, edit, and read articles. Applying so-called RESTful principles to the design of this application, the following occurs:

• Each submitted article has a unique URL, for example:

  http://somedomain.com/articles/173
  

  We only require that the URL be unique for each article; for instance

  http://somedomain.com/articles/list.php?id=173
  

  also fulfils this requirement.

  Tip

  
  

  Although REST requires that URLs be unique, it does not follow that each resource must have a corresponding physical page. In many cases the resource is generated by the web service at the time of the requestfor example, by reference to a database.

• To retrieve an article to read or edit, our client application would simply use an HTTP GET request to the URL of the article in question.

• To upload a new article, a POST request would be used, containing information about the article. The server would respond with the URL of the newly uploaded article.

• To upload an edited article, a PUT request would be used, containing the revised content.

• HTTP DELETE would be employed to delete a particular article.

In this way, the web service is using an interface familiar to anyone who has used the World Wide Web. We do not need to devise a library of API methods for sending or retrieving information; we already have them in the form of the standard HTTP methods.

Note

The World Wide Web itself is a REST application.

Query Information Using GET

An important issue concerning the use of the HTTP GET request in a RESTful application is that it should never change the server state. To put it another way: We only use GET requests to ask for information from the server, never to add or alter information already there.

POST, PUT, and DELETE calls can all change the server status in some way.

Stateless Operation

All server exchanges within a RESTful application should be stateless. By stateless we mean that the call itself must contain all the information required by the server to carry out the required task, rather than depending on some state or context currently present on the server. We cannot, for example, require the server to refer to information sent in previous requests.