Outils pour utilisateurs

Outils du site


devarchitecture:api_rest

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
devarchitecture:api_rest [2025/11/02 07:40]
74.7.227.242 ancienne révision (2025/11/02 07:28) restaurée
devarchitecture:api_rest [2025/11/02 07:53] (Version actuelle)
74.7.227.242 ancienne révision (2025/11/02 07:32) restaurée
Ligne 9: Ligne 9:
 L'architecture REST est un ensemble de principe directeurs auxquels un développeur doit adhérer avant de pouvoir considérer son API comme "RESTful". L'architecture REST est un ensemble de principe directeurs auxquels un développeur doit adhérer avant de pouvoir considérer son API comme "RESTful".
  
-  * Architecture client-serveur: Chaque API se comporte comme un client faisant une demande à un serveur. (en HTTP notamment). +  * **Architecture client-serveur:** Chaque API se comporte comme un client faisant une demande à un serveur. (en HTTP notamment). 
-  * Sans-Etat: Les application "sans-Etat" ne maintiennent pas de connexion avec leur ressources +  * **Sans-Etat:** Les application "sans-Etat" ne maintiennent pas de connexion avec leur ressources 
-  * Avec mise en cache: Une API REST doit permettre la mise en cache des données fréquemment demandées, réduction bande passante, de la latence de la charge du serveur). +  * **Avec mise en cache:** Une API REST doit permettre la mise en cache des données fréquemment demandées, réduction bande passante, de la latence de la charge du serveur). 
-  * Interface uniforme: Le client interagit avec le serveur selon une manière définie, indépendamment de l'appareil ou de l'application. +  * **Interface uniforme:** Le client interagit avec le serveur selon une manière définie, indépendamment de l'appareil ou de l'application. 
-  * Identification des ressources: L'API doit avoir une URI (identifiant de ressource uniforme) spécifique pour chaque ressource. +  * **Identification des ressources:** L'API doit avoir une URI (identifiant de ressource uniforme) spécifique pour chaque ressource. 
-  * Auto-Descriptif: Comprend des métadonnées telles que Content-Type qui décrit comment interpréter la réponse. +  * **Auto-Descriptif:** Comprend des métadonnées telles que Content-Type qui décrit comment interpréter la réponse. 
-  * HATEOAS: (Hypermédia comme moteur d'état de l'application) : la réponse du serveur comprend les URI des méthodes supplémentaires auxquelles le client peut accéder à l'aide des données de réponse. +  * **HATEOAS:** (Hypermédia comme moteur d'état de l'application) : la réponse du serveur comprend les URI des méthodes supplémentaires auxquelles le client peut accéder à l'aide des données de réponse. 
-  * Système en couches: Une API peut avoir plusieurs couches, telles que des serveurs porxy ou des dispositifs de répartition de charge, et le serveur d'extrémité peut déployer des serveurs supplémentaires pour formuler une réponse. Le client ne sait pas quel serveur répond à la requête. Un système en couches rend une API plus évolutive.  +  * **Système en couches:** Une API peut avoir plusieurs couches, telles que des serveurs porxy ou des dispositifs de répartition de charge, et le serveur d'extrémité peut déployer des serveurs supplémentaires pour formuler une réponse. Le client ne sait pas quel serveur répond à la requête. Un système en couches rend une API plus évolutive.  
-  * Code sur demande (facultatif): L'API peut envoyer du code exécutable tel que des applets JAVA ou JavaScript.+  * **Code sur demande (facultatif):** L'API peut envoyer du code exécutable tel que des applets JAVA ou JavaScript.
  
  
devarchitecture/api_rest.1762069208.txt.gz · Dernière modification: 2025/11/02 07:40 de 74.7.227.242