web-dev-qa-db-fra.com

REST API avec HTTP/2

Il y a quelques mois, HTTP/2 a été publié sous la forme RFC7540 . Comment cela affectera-t-il l'API REST existante construite sur HTTP/1.1

Selon wikipedia , HTTP/2 a ajouté de nouvelles fonctionnalités. Comment pouvons-nous Profiter de ces nouvelles fonctionnalités?

N'hésitez pas à améliorer cette question.

Merci.

apiresthttphttp2
23
Sorter

La sémantique principale de HTTP a été conservée dans HTTP/2. Cela signifie qu'il a toujours HTTP methods tel que GET, POST, etc., HTTP headers et URIs pour identifier les ressources.

Ce qui a changé dans HTTP/2 par rapport à HTTP/1.1, c’est la manière dont la sémantique HTTP (par exemple, "Je souhaite PUT ressource /foo sur l’hôte domain.com") est acheminée sur le réseau filaire.

Dans cette optique, les API REST basées sur HTTP/1.1 continueront à fonctionner de manière transparente comme auparavant, sans aucune modification à apporter aux applications. Le conteneur Web qui exécute les applications se chargera de la traduction du nouveau format wire en une sémantique HTTP habituelle pour le compte des applications, et l'application ne verra que la sémantique HTTP de niveau supérieur, qu'il ait été transporté via HTTP/1.1 ou HTTP /. 2 sur le fil.

Le format filaire HTTP/2 étant plus efficace (notamment en raison du multiplexage et de la compression), les API REST en plus de HTTP/2 en bénéficieront également.

L'autre amélioration majeure présente dans HTTP/2, HTTP/2 Push, vise le téléchargement efficace de ressources corrélées, et elle n'est probablement pas utile dans le cas d'utilisation REST.

Une exigence typique de HTTP/2 doit être déployée sur TLS . Cela nécessite que les déployeurs passent de http à https et configurent l'infrastructure requise pour la prendre en charge (achat des certificats auprès d'une autorité de confiance, renouvellement, etc.). .

23
sbordet

La spécification HTTP/2 n'a intentionnellement pas introduit de nouvelle sémantique pour le programmeur d'application. En fait, les principales bibliothèques côté client (NSUrlSession sur iOS, OkHttp sur Android, React Native, JS dans un environnement de navigateur) prennent en charge HTTP/2 de manière transparente pour vous en tant que développeur.

En raison de la capacité de HTTP/2 à multiplexer de nombreuses demandes sur une seule connexion TCP, certaines optimisations précédemment mises en œuvre par les développeurs d'applications, telles que le traitement par lots des demandes deviendraient obsolètes et même contre-productives. 

La fonction Push sera probablement utilisée pour diffuser des événements et pourra remplacer les interrogations et éventuellement les websockets dans certaines applications.

Une des applications possibles de la fonction serveur Push dans les API HTTP/2 vers REST est la capacité d’accélérer les applications existantes au niveau du proxy inverse en transmettant les demandes anticipées au client au lieu d’attendre qu’elles arrivent. C'est à dire. Envoyez les réponses au profil de l'utilisateur et aux autres appels d'API courants juste après la fin de la demande de connexion.

Cependant, Push n’est pas encore largement implémenté sur l’ensemble des infrastructures client et serveur. 

4
DenisM

Le principal avantage que je vois est Server Push pour les API hypermédia RESTful, qui contiennent des références à des ressources, souvent des URL absolues dépendantes du domaine, telles que /post/12.

Exemple: GET https://api.foo.bar/user/3 

{
  "_self": "/user/3"
  "firstName": "John",
  "lastName": "Doe",
  "recentPosts": [
    "/post/3",
    "/post/13",
    "/post/06
    ]
}

HTTP/2 Push peut être utilisé pour remplir de manière préemptive le cache du navigateur si le serveur sait que le client voudra probablement effectuer certaines demandes GET à l'avenir.

Dans l'exemple ci-dessus, si HTTP/2 Server Push est activé et correctement configuré, il pourrait fournir /post/3, /post/13 et /post/06 ainsi que /user/3. La succession de GETs à l'une de ces publications entraînerait des réponses en mémoire cache. En outre, le résumé de cache brouillon permettrait au client d’envoyer des informations sur l’état de son cache, évitant ainsi des envois inutiles. Cela est beaucoup plus pratique pour les API basées sur Hypermedia que pour les corps incorporés tels que HAL .

Plus d’informations sur les raisons ici: Problèmes liés à l’incorporation dans REST aujourd’hui et à la manière de le résoudre avec HTTP/2 .

0
Jules Randolph