1. Introduction

1. Introduction

Les applications autres que la navigation Web utilisent souvent HTTP [HTTP] comme substrat, une pratique parfois appelée création d'"API basées sur HTTP", "API REST" ou simplement "API HTTP". Cela se fait pour diverses raisons, notamment:

• familiarité des implémenteurs, spécificateurs, administrateurs, développeurs et utilisateurs;

• disponibilité d'une variété d'implémentations de clients, serveurs et proxies;

• facilité d'utilisation;

• disponibilité des navigateurs Web;

• réutilisation de mécanismes existants comme l'authentification et le chiffrement;

• présence de serveurs et clients HTTP dans les déploiements cibles; et

• sa capacité à traverser les pare-feu.

Ces protocoles sont souvent ad hoc, destinés uniquement au déploiement par un ou quelques serveurs et à la consommation par un ensemble limité de clients. En conséquence, un ensemble de pratiques et d'outils est apparu autour de la définition d'API basées sur HTTP qui favorisent ces conditions.

Cependant, lorsqu'une telle application a plusieurs implémentations séparées, est déployée sur plusieurs serveurs non coordonnés et est consommée par des clients divers (comme c'est souvent le cas pour les API HTTP définies par des efforts de normalisation), les outils et pratiques destinés à un déploiement limité peuvent devenir inappropriés.

Ce décalage est largement dû au fait que les clients et serveurs de l'API implémenteront et évolueront à des rythmes différents, ce qui nécessite que des déploiements avec différentes fonctionnalités et versions coexistent. En conséquence, les concepteurs d'API basées sur HTTP destinées à de tels déploiements doivent examiner plus attentivement comment l'extensibilité du service sera gérée et comment les différentes exigences de déploiement seront satisfaites.

Plus généralement, un protocole d'application utilisant HTTP fait face à un certain nombre de décisions de conception, notamment:

• Doit-il définir un nouveau schéma URI? Utiliser de nouveaux ports?

• Doit-il utiliser des méthodes et codes d'état HTTP standard ou en définir de nouveaux?

• Comment peut-on extraire une valeur maximale de l'utilisation de HTTP?

• Comment coexiste-t-il avec d'autres utilisations de HTTP -- en particulier la navigation Web?

• Comment peut-on éviter les problèmes d'interopérabilité et les "impasses de protocole"?

La section 2 définit quand ce document s'applique, la section 3 examine les propriétés de HTTP qui sont importantes à préserver, et la section 4 contient les meilleures pratiques pour la spécification d'applications qui utilisent HTTP.

Il est écrit principalement pour guider les efforts de l'IETF visant à définir des protocoles d'application utilisant HTTP pour le déploiement sur Internet, mais pourrait être applicable dans d'autres situations. Notez que les exigences ici ne s'appliquent pas nécessairement au développement d'extensions HTTP génériques.

Ce document rend obsolète [RFC3205] pour refléter l'expérience et les développements concernant HTTP dans l'intervalle.