Les 5 règles et ½ de l’API ReST

ou plutôt les 5 contraintes et ½

Separation of Concerns (Client / Server)

  • L’API ReST n’est pas concernée par l’affichage, les interactions utilisateur et la session.

  • Tous ces éléments doivent être gérés par le client (Ex. : application web frontend).

Stateless

  • Une API ReST ne doit pas maintenir de session ou de contexte.

Communication must be stateless in nature..., such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn’t have to manage resource usage across requests.

Layered

  • La présence de connecteurs intermédiaires doit être implicite pour le client et le serveur (composant de cache / sécurité etc…).

Uniforme

  • L’interface est uniforme à tous les niveaux. Tous les éléments (et connecteurs) communiquent en utilisant la même interface.

  • Chaque ressource est identifiée de façon unique et canonicalisée avec son URI (URL ou URN dont voici deux exemples respectifs https://www.googleapis.com/books/v1/volumes/-DNcBAAAQBAJ et isbn:9780134051994).

In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; selfdescriptive messages; and, hypermedia as the engine of application state.

Cacheable

  • Il doit être possible de mettre les ressources en cache à tous les niveaux (front, connecteur intermédiaire, back, etc…).

  • Il doit être possible d’utiliser les implémentations standards de cache HTTP.

Code à la demande

Règle optionnelle ou plutôt inadaptée.

C’est le paramètre extra que l’on retrouve dans certaines RFC pour garder un peu de souplesse.