REST is an acronym for Representational State Transfer. This is a set of constraints that an API should follow. If you're API follows these constrains then it is considered to be RESTful. These constraints are:
- A client-server model,
- Stateless interaction,
- Uniform interface.
This does not make REST much clearer to understand.
The Client-Server model defines the relationship between the server, typically your API, and the client. The client could take the form of a mobile app, a desktop application or a webpage.
This constraint dictates that a server provides the client with a service or resource. Clients should be able to request these resources.
This constraint dictates that a server should not store any information with relation to state. Any information about state should be provided by the client. This means that the client is responsible for providing the server with all the information necessary for them to fulfill a request.
This means that your server should not store information about if a client is logged in. Instead the client should provide some data about they're access every time they make a request.
The interface you use to interact with your RESTful API should use the HTTP verbs. The uniform interface should be able to perform CRUD actions on resources.
The common ones are:
- GET
- POST
- PUT
- DELETE
but there a lot more. You do not have to provide definitions for all of the HTTP verbs.
We have used the word resources in this article a lot. A resource could be a virtual thing such as an image, video or file. It could be a real life object represented digitally such as a customer or an employee. Or you can provide a collection of objects such as an organisation.
To conform to REST each resource should be unique and there should be a unique path to each resource. This typically takes the form in resouceType/ID e.g. employee/69af3.