Chapter 10. REST

REST stands for REpresentational State Transfer, and in contrast to protocols such as SOAP or XML-RPC, it is more a philosophy or a set of principles than a protocol in its own right. REST is a set of ideas about how data can be transferred elegantly, and although it’s not tied to HTTP, in this book we’ll talk about it in the context of HTTP. REST takes great advantage of the features of HTTP, so the earlier chapters covering this and the more detailed topics of headers and verbs are all coming together to support our knowledge of REST.

In a RESTful service, we use four HTTP verbs to give us a basic set of CRUD (Create, Read, Update, Delete) functionality: POST, GET, PUT and DELETE. It is also possible to see implementations of other verbs in RESTful services, such as PATCH to allow partial update of a record, but the basic four are the basis of a RESTful service.

The operations are applied to resources in a system. The “Representational State Transfer” name is accurate; RESTful services deal in transferring representations of resources. A representation might be JSON or XML, or indeed anything else. So what is a resource? Well, everything is. Each individual data record in your system is a resource. At the first stage of API design, you could start with each database row being an individual resource. If your system were mythical blog engine, for example, your resources might be posts, categories, and authors. Every resource has a URI (Uniform Resource Identifier), ...

The best content for your career. Discover unlimited learning
on demand for around $1/day.