Constraints of REST API

REST (Representational State Transfer) is a set of architectural principles for building web services. RESTful APIs, which conform to these principles, have several constraints that must be followed in order to be considered truly RESTful.

These constraints include:

  • Client-Server: The client and server should be separate entities, with the server responsible for handling requests and the client responsible for handling the user interface.
  • Stateless: The server should not store any information about the client’s state, so that each request can be handled independently.
  • Cacheable: Responses should be marked as cacheable or non-cacheable, so that clients can optimize the use of network resources.
  • Layered System: The API should be designed to work with a layered system, with each layer handling a specific responsibility.
  • Code on Demand (optional): Servers can provide executable code to clients, allowing for more dynamic and adaptive interactions.
  • Self-descriptive message: Each message must contain enough information to describe how to process the message.
  • URIs identification of resources: Resources should be identified by URIs, which can be used to locate the resource and interact with it using standard methods.
  • Standard methods: The API should use standard HTTP methods (such as GET, POST, PUT, and DELETE) to interact with resources.

By following these constraints, RESTful APIs can ensure that they are scalable, maintainable, and easily understood by developers.