REST design principles

REST is designed based on a set of principles that help create scalable, maintainable, and interoperable web services. Here is a list of key design principles for designing REST:

  1. Client-Server: Client and server applications are completely independent in a REST API. The client application communicates with the server application through a URI, and both applications cannot modify each other. Server applications and client applications both transfer data by requesting data via HTTP.

  2. Stateless: In stateless communication, the client request contains all the necessary information needed for the server to understand and process the request. Here, the server should not store any information about the client's state between requests.

  3. Cacheable: Responses from the server can be marked as cacheable or non-cacheable. This helps in providing a fast response. When a response is marked as cacheable, the server response will be stored and reused for the same request in the future. This improves performance on the client side while increasing scalability on the server side.

  4. Layered System Architecture: In REST APIs, request calls and responses go through different layers. There might be a number of different intermediaries in the communication loop. REST APIs need to be designed so that neither the client nor the server can tell whether they are communicating with the end application or an intermediary.

  5. Uniform Interface: Requests for the same resources should look the same. Requests are maintained by a uniform interface and defined by a set of constraints, including Resource Identification (resources identified by URIs), Resource Manipulation through Representations (clients manipulate resources through the representation provided by the server), and Self-Descriptive Messages (each message from the server to the client contains all the information needed to understand and process the message).

  6. Code on Demand: REST APIs are mainly designed to share static resources. However, in certain cases, a response from the server may also contain executable codes like Java applets. In this case, the code should only run on demand.