Basics of REST

Representational State Transfer (REST) is an architectural style for creating web services. REST is not standard, but it defines a set of constraints defined by Roy Fielding. The six constraints are as follows:

• Stateless: The server doesn't hold any information about the client state.
• Client server: The client and server act independently. The server does not send any information without a request from the client.
• Cacheable: Many clients often request the same resources; therefore, it is useful to cache responses in order to improve performance.
• Uniform interface: Requests from different clients look the same. Clients may include, for example, a browser, a Java application, and a mobile application.
• Layered system: REST allows us to use a layered system architecture.
• Code on demand: This is an optional constraint.

The uniform interface is an important constraint and it stipulates that every REST architecture should have the following elements:

• Identification of resources: There are resources with their unique identifiers, for example, URIs in web-based REST services. REST resources should expose easily understood directory structure URIs. Therefore, a good resource naming strategy is very important.
• Resource manipulation through representation: When making a request to a resource, the server responds with a representation of the resource. Typically, the format of the representation is JSON or XML.
• Self descriptive messages: Messages should have sufficient information that the server knows how to process them.
• Hypermedia and the Engine of Application State (HATEOAS): Responses can contain links to other areas of service.

The RESTful web service that we are going to develop in the following topics follows the REST architectural principles.