API REST (API RESTful)

Cet article fait partie du

Guide to building an enterprise API strategy

• qui comprend également:
• 5 principales raisons d’adopter une plate-forme de gestion D’API
• 10 directives de sécurité et meilleures pratiques de L’API
• liste de contrôle et meilleures pratiques la langue de l’internet. Avec l’augmentation de l’utilisation du cloud, les API sont utilisées par les consommateurs du cloud pour exposer et organiser l’accès aux services web., REST est un choix logique pour créer des API qui permettent aux utilisateurs de se connecter, de gérer et d’interagir avec les services cloud de manière flexible dans un environnement distribué. Les API RESTful sont utilisées par des sites tels Qu’Amazon, Google, LinkedIn et Twitter.

  fonctionnement des API RESTful

  Une API RESTful décompose une transaction pour créer une série de petits modules. Chaque module traite une partie sous-jacente de la transaction. Cette modularité offre aux développeurs beaucoup de flexibilité, mais il peut être difficile pour les développeurs de concevoir leur API REST à partir de zéro., Actuellement, plusieurs entreprises fournissent des modèles pour les développeurs à utiliser; les modèles fournis par Amazon S3, Cloud Data Management Interface (CDMI) et OpenStack Swift sont les plus populaires.

  Une API RESTful utilise des commandes pour obtenir des ressources. L’état d’une ressource à un horodatage donné est appelé représentation de ressource., Une API RESTful utilise des méthodologies HTTP existantes définies par le protocole RFC 2616, telles que:

  • GET pour récupérer une ressource;
  • PUT pour modifier l’état ou mettre à jour une ressource, qui peut être un objet, un fichier ou un bloc;
  • POST pour créer cette ressource; et
  • DELETE pour la supprimer.

  avec REST, les composants en réseau sont une ressource à laquelle l’utilisateur demande l’accès like comme une boîte noire dont les détails d’implémentation ne sont pas clairs. Tous les appels sont sans état; rien ne peut être conservé par le service RESTful entre les exécutions.,

  les formats de données pris en charge par L’API REST incluent:

  • application / json
  • application / xml
  • application/x-WBE+xml
  • application/x-www-form-urlencoded
  • multipart / form-data

  utilise

  parce que les appels sont sans état, REST est utile dans le cloud applications. Les composants sans état peuvent être librement redéployés en cas de défaillance, et ils peuvent évoluer pour s’adapter aux changements de charge. En effet, toute demande peut être dirigée vers n’importe quelle instance d’un composant; il ne peut y avoir rien enregistré qui doit être mémorisé par la transaction suivante., Cela rend REST préférable pour une utilisation sur le web. Le modèle RESTful est également utile dans les services cloud car la liaison à un service via une API consiste à contrôler la façon dont l’URL est décodée. Le Cloud computing et les microservices sont presque certains de faire de la conception D’API RESTful la règle à l’avenir.

  contraintes de conception et D’Architecture de L’API RESTful

  La conception de L’API RESTful a été définie par le Dr Roy Fielding dans sa thèse de doctorat de 2000., Pour être une véritable API RESTful, un service web doit respecter les six contraintes architecturales REST suivantes:

  • utilisation d’une interface uniforme (UI). Les ressources doivent être identifiables de manière unique via une seule URL, et uniquement en utilisant les méthodes sous-jacentes du protocole réseau, telles que DELETE, PUT et GET avec HTTP, s’il est possible de manipuler une ressource.
  • Client-serveur basée sur. Il devrait y avoir une délimitation claire entre le client et le serveur. Les problèmes D’interface utilisateur et de collecte de demandes sont le domaine du client., L’accès aux données, la gestion de la charge de travail et la sécurité sont le domaine du serveur. Ce couplage lâche du client et du serveur permet à chacun d’être développé et amélioré indépendamment de l’autre.
  • des opérations passives. Toutes les opérations client-serveur doivent être sans état, et toute gestion d’état requise doit avoir lieu sur le client, pas sur le serveur.
  • mise en cache des ressources RESTful. Toutes les ressources doivent autoriser la mise en cache, sauf indication explicite que la mise en cache n’est pas possible.
  • système de Couches. REST permet une architecture composée de plusieurs couches de serveurs.,
  • Code à la demande. La plupart du temps, un serveur renvoie des représentations statiques de ressources sous forme XML ou JSON. Cependant, si nécessaire, les serveurs peuvent envoyer du code exécutable au client.

  défis communs de L’API REST

  outre les contraintes de conception et d’architecture, les individus devront faire face à certains défis avec les API REST. Certains concepts qui peuvent être difficiles peuvent inclure:

  • cohérence des points de terminaison — les chemins des points de terminaison doivent être cohérents en suivant les normes Web communes, ce qui peut être difficile à gérer.,
  • API versioning — les URL de point de terminaison ne doivent pas être invalidées lorsqu’elles sont utilisées en interne ou avec d’autres applications.
  • longs temps de réponse et trop de données-la quantité de ressources renvoyées peut augmenter en taille dans le temps, ce qui augmente la charge et les temps de réponse.
  • chemins de Navigation et emplacements d’entrée utilisateur-comme REST utilise des chemins D’URL pour les paramètres d’entrée, la détermination des espaces D’URL peut être difficile.,
  • sécurité has qui a beaucoup d’aspects à surveiller, y compris l’utilisation de:
    • HTTPS;
    • bloquer l’accès à partir d’adresses IP et de domaines inconnus;
    • valider les URL;
    • bloquer des charges utiles inattendues;
    • journaliser les demandes; et
    • enquêter sur les échecs.
  • authentification use utilisez des méthodes d’authentification courantes telles que L’authentification HTTP basic (qui permet un nom d’utilisateur encodé en base64:chaîne de mot de passe), les clés API, les jetons Web JSON et autres jetons d’accès. OAuth 2.0, par exemple, est bon pour le contrôle d’accès.,
  • demandes et données — les demandes peuvent contenir plus de données et de métadonnées que nécessaire ou plus de demandes peuvent être nécessaires pour obtenir toutes les données. Les API peuvent être ajustées pour cela.
  • Les tests D’API can peuvent être un long processus à configurer et à exécuter. Chaque partie du processus peut être longue ou difficile. Les tests peuvent également être effectués en ligne de commande avec l’utilitaire Curl., Les parties du processus de test qui peuvent être difficiles comprennent:
    • configuration initiale
    • mises à jour de schéma
    • combinaisons de paramètres de Test
    • appels D’API de séquence
    • valider les paramètres de test
    • intégration du système
  • définir les codes d’erreur et les messages.
    • avec les codes d’erreur, il est plus courant d’utiliser des codes D’erreur HTTP standard. Ceux-ci sont reconnus plus souvent par les clients et les développeurs.
    • La gestion des erreurs peut ne pas avoir de moyen de distinguer si une réponse réussit ou non, en plus de l’analyse du corps ou de la vérification d’une erreur.,

  REST vs SOAP

  REST et Simple Object Access Protocol (SOAP) offrent différentes méthodes pour invoquer un service web. REST est un style architectural, tandis que SOAP définit une spécification de protocole de communication standard pour L’échange de messages basé sur XML. Les applications REST peuvent utiliser du savon.

  Les services web RESTful sont sans état. Une implémentation basée sur REST est simple par rapport à SOAP, mais les utilisateurs doivent comprendre le contexte et le contenu transmis, car il n’y a pas d’ensemble standard de règles pour décrire L’interface des services web REST., Les services REST sont utiles pour les appareils à profil restreint, tels que les appareils mobiles, et sont faciles à intégrer aux sites Web existants.

  SOAP nécessite moins de code de plomberie-c’est-à-dire un code d’infrastructure de bas niveau qui relie les modules de code principaux entre eux-que la conception de services REST. Le langage de Description des services Web décrit un ensemble commun de règles pour définir les messages, les liaisons, les opérations et l’emplacement du service. Les services web SOAP sont utiles pour le traitement et l’invocation asynchrones.

  Historique des API RESTful

  avant REST, les développeurs utilisaient SOAP pour intégrer les API., Pour faire un appel, les développeurs handwrote un document XML avec un appel de procédure à distance (RPC) dans le corps. Ils ont ensuite spécifié le point de terminaison et postent leur enveloppe SOAP sur le point de terminaison.

  en 2000, Roy Fielding et un groupe de développeurs ont décidé de créer une norme afin que n’importe quel serveur puisse parler à n’importe quel autre serveur. Il a défini REST et les contraintes architecturales expliquées ci-dessus dans sa thèse de doctorat de 2000 à L’Université de Californie à Irvine. Ces règles universelles facilitent l’intégration des logiciels par les développeurs.,

  Salesforce a été la première entreprise à vendre une API dans le cadre de son package « Internet as a Service » en 2000. Cependant, peu de développeurs étaient réellement en mesure d’utiliser l’API XML compliquée. Ensuite, eBay a construit une API REST, qui a étendu son marché à n’importe quel site pouvant accéder à son API. Cela a attiré l’attention d’un autre géant du commerce électronique, et Amazon a annoncé son API en 2002.

  Flickr a lancé sa propre API RESTful en août 2004, permettant aux blogueurs d’intégrer facilement des images sur leurs sites et leurs flux de médias sociaux., Facebook et Twitter ont tous deux publié leurs API en 2006, flambant sous la pression des développeurs qui ont gratté les sites et créé des API « Frankenstein ». Lorsque Amazon Web Services (AWS) a aidé à lancer le cloud en 2006, les développeurs ont pu accéder à l’espace de données en quelques minutes à l’aide de L’API REST D’AWS, et la demande d’API publiques a rapidement augmenté.

  Depuis lors, les développeurs ont adopté les API RESTful, les utilisant pour ajouter des fonctionnalités à leurs sites web et applications. Aujourd’hui, les API REST sont considérées comme « l’épine dorsale d’internet. »