REST architecture

Introduction

In the Russian-speaking part of the Internet there is a large number of articles devoted to web services based on SOAP and XML-RPC, but for some reason there is almost nothing about the completely worthy (but less common) architecture of REST.

This article describes the basics of this architecture, the possibilities and examples of its use.

What is REST

REST (Representational state transfer) is a software architecture style for distributed systems, such as the World Wide Web, which is typically used to build web services. The term REST was introduced in 2000 by Roy Fielding, one of the authors of the HTTP protocol. Systems that support REST are called RESTful systems.
')
In general, REST is a very simple information management interface without the use of any additional internal layers. Each piece of information is uniquely identified by a global identifier, such as a URL. Each URL in turn has a strictly specified format.

And now the same thing is more obvious:

The absence of additional internal layers means the transfer of data in the same form as the data itself. Those. we do not wrap the data in XML, as SOAP and XML-RPC do, do not use AMF, as Flash does, etc. Just give yourself the data.

Each unit of information is uniquely identified by a URL - this means that the URL is essentially the primary key for the data unit. Those. for example, the third book from the bookshelf will look like / book / 3, and 35 the page in this book will be / book / 3 / page / 35. From here it turns out a strictly specified format. And it doesn't matter at all what format the data is located at / book / 3 / page / 35 - it can be HTML, a scanned copy in the form of a jpeg-file, and a Microsoft Word document.

How service information is managed is entirely based on the data transfer protocol. The most common protocol is of course HTTP. So, for HTTP, the action on data is set using the methods: GET (get), PUT (add, replace), POST (add, change, delete), DELETE (delete). Thus, CRUD (Create-Read-Updtae-Delete) actions can be performed with all 4 methods, or only with GET and POST.

Here is how it will look like on an example:

GET / book / - get a list of all books
GET / book / 3 / - get the book number 3
PUT / book / - add a book (data in the request body)
POST / book / 3 - change the book (data in the request body)
DELETE / book / 3 - delete a book

IMPORTANT ADDITION: There are so-called REST-Patterns that differ in associating HTTP methods with what they do. In particular, different patterns treat POST and PUT differently. However, PUT is intended for creation, replay or update, for POST it is not defined () . Therefore, my example will be correct both in this form and in the form if you swap POST and PUT.

In general, POST can be used simultaneously for all change actions:
POST / book / - add a book (data in the request body)
POST / book / 3 - change the book (data in the request body)
POST / book / 3 - delete the book (the request body is empty)

This allows you to sometimes bypass the unpleasant moments associated with the rejection of PUT and DELETE.

Using REST to build Web services.

As you know, a web service is an application running on the World Wide Web and access is provided via the HTTP protocol, and information is exchanged using the XML format. Consequently, the format of the data transmitted in the request body will always be XML.

For each unit of information (info), 5 actions are defined. Namely:

GET / info / (Index) - gets a list of all objects. As a rule, this is a simplified list, i.e. containing only the fields of the identifier and the name of the object, without remaining data.

GET / info / {id} (View) - gets full information about the object.

PUT / info / or POST / info / (Create) - creates a new object. Data is transmitted in the request body without encoding, even urlencode. In PHP, the request body can be obtained in this way:

function getBody() {
if (!isset($HTTP_RAW_POST_DATA))
$HTTP_RAW_POST_DATA = file_get_contents("php://input");
return $HTTP_RAW_POST_DATA;
}

POST / info / {id} or PUT / info / {id} (Edit) - modifies data with id {id}, possibly replaces it. Data is also transmitted in the request body, but unlike PUT, there is some nuance here. The fact is that the POST request implies the presence of urldecoded-post-data. Those. if not to apply coding - this is a violation of the standard. Then whoever he wants, some do not pay attention to the standard, some use some post variable.

DELETE / info / {id} (Delete) - deletes data with id {id}.

Once again, in our example, / info / - can be based on some other information, which can (and should) be reflected in the URL:

/ data / 4 / otherdata / 6 / info / 3 / ... and the like.

What conclusions can be drawn from this:

As you can see, the REST architecture is very simple in terms of usage. By the appearance of the incoming request, you can immediately determine what it does without understanding the formats (unlike SOAP, XML-RPC). Data is transferred without the use of additional layers, so REST is considered less resource-intensive, since there is no need to parse the request in order to understand what it should do and it is not necessary to transfer data from one format to another.

Practical use.

The most important advantage of services is that any system can work with them, be it a website, flash, a program, etc., since the methods of XML parsing and execution of HTTP requests are present almost everywhere.

The REST architecture allows you to seriously simplify this task. Of course, in reality, the fact that the described is not enough, because you can not give anyone the opportunity to change information, that is, you need more authorization and authentication. But this is quite simply resolved by using different types of sessions or simply HTTP Authentication.

Related Links:

http://en.wikipedia.org/wiki/REST
http://ru.wikipedia.org/wiki/Web service