Representational State Transfer, or REST, is an increasingly common software architecture for creating APIs. REST, which was introduced by Roy Fielding in 2000, is not a technology in and of itself, but a set principles used to create services. RESTful APIs are almost always implemented using HTTP, but this is not a strict requirement. The following list enumerates a number of principles behind RESTful design.
- RESTful designs should have a single base URL, and a directory-like URL structure. For example, a blog API could have a base URL of /blog. Individual blog entries for a given day could then be made accessible using a URL structure like /blog/posts/2013/03/17/.
- Hypermedia as the engine of application state (HATEOAS). Clients should be able to navigate the entire API using only hyperlinks provided by the server. For example, after accessing an API’s entry point, the server should provide links that the client can use to navigate the API.
- The server should not maintain any client state, such as sessions. Instead, every client request should contain all of the information required to define the state. This principle increases scalability by simplifying the server.
- Server responses should declare whether they can be cached. This declaration can be either explicit or implicit. When possible, a response should be cacheable, as it improves performance and scalability.
- RESTful designs should utilize the underlying protocol’s vocabulary as much as possible. For example, CRUD (create, read, update, and delete) operations are implemented using HTTP’s POST, GET, PUT, and DELETE verbs, respectively. Additionally, servers should respond with appropriate status codes whenever possible.