Representational State Transfer (REST)

REST is not a protocol.

REST (Representational State Transfer) is a software architectural style for creating web services. It is an alternative to Simple Object Access Protocol (SOAP)-based web services protocol, which rely on the language for message exchange.

RESTful services are based on the Hypertext Transfer Protocol (HTTP) protocol.

REST emphasizes scalability, simplicity, and modifiability, making it a popular choice for creating web APIs (Application Programming Interfaces) that can be consumed by a wide range of clients, from web browsers to mobile devices and other software applications.

One of the key features of REST is its statelessness, which means that the server does not maintain any session state for the client. Instead, each request from the client contains all the necessary information for the server to process the request and generate a response. This allows RESTful services to be highly scalable, as they can handle large numbers of concurrent requests without consuming significant server resources.

RESTful rules

Hypermedia is a key aspect of RESTful API design, and it refers to the use of hypertext links in API responses to allow clients to discover and navigate the API. Hypermedia is sometimes referred to as the "engine of application state" because it enables clients to discover and interact with resources in a stateful manner.

There are several rules or constraints associated with hypermedia-driven RESTful API design:

  1. Resources are identified by URIs: Each resource in the API should be identified by a unique URI.

  2. Use of standard HTTP methods: The HTTP methods (GET, POST, PUT, DELETE, etc.) should be used to manipulate resources.

  3. Use of hyperlinks: Resources should contain hyperlinks to other related resources, allowing clients to discover and navigate the API. Hypermedia as the Engine of Application State (H.A.T.E.O.A.S)

  4. Stateless communication: Each request from a client to the server should contain all of the information necessary to complete the request, and should not rely on server-side state.

  5. Use of media types: The API should use standardized media types (such as JSON or XML) to describe resource representations.

  6. Self-descriptive messages: Responses should include enough information (such as link relations and media types) to enable clients to understand the meaning and context of the response.

By following these rules, APIs can provide a more flexible and discoverable interface for clients, while also promoting loose coupling between clients and servers.


Children
  1. Hypermedia as the Engine of Application State (H.A.T.E.O.A.S)

Backlinks