Qu'est-ce qu'une API REST?

Explication détaillée de l'API REST: Facile à comprendre les technologies de service réseau les plus couramment utilisées

REST, qui signifie «transfert d'état de représentation», est actuellement la technologie de service réseau la plus utilisée. Bien que son nom soit un peu abstrait, l'API REST est essentiellement un moyen pour deux systèmes informatiques de communiquer à l'aide de la technologie HTTP commune dans les navigateurs Web et les serveurs.

Dans le développement de logiciels, le partage de données entre les systèmes est toujours une exigence de base. Par exemple, lors de l'achat d'une assurance automobile, la compagnie d'assurance doit obtenir vos informations personnelles et vos informations sur les véhicules, elle doit donc demander des données auprès des agences d'enregistrement des véhicules, des agences de crédit, des banques et d'autres systèmes. Tout cela se fait de manière transparente en temps réel pour déterminer si un assureur peut offrir une police concurrentielle.

API (interface de programmation d'application) réalise une telle communication intersystème en fournissant une interface pour la communication inter-système. Le repos n'est qu'un style API largement adopté, et nous l'utilisons pour communiquer avec les parties internes et externes d'une manière cohérente et prévisible. Cela peut être comparé à la façon dont nous envoyions des lettres avec des timbres, des adresses et des enveloppes d'une manière ou d'une autre pour nous assurer qu'ils ont été livrés et lus.

Le repos est souvent utilisé pour les interactions des personnes dans les systèmes de réseau, tels que la récupération et la mise à jour des informations de compte dans les applications de médias sociaux.

points clés

1. REST API utilise HTTP pour faciliter la communication entre les systèmes informatiques, permettant à divers services (tels que les agences d'enregistrement des véhicules, les agences de crédit et les banques) de partager des données en temps réel, fournissant ainsi des services tels que des devis d'assurance automobile.
2. REST L'API suit un ensemble de suggestions pour créer des services de réseau, y compris l'architecture client-serveur, le apatritude, la mise en cache et les systèmes hiérarchiques, ce qui en fait un moyen simple et efficace d'interagir avec les systèmes réseau.
3. L'implémentation et l'utilisation des API REST doivent considérer la cohérence des points de terminaison, le contrôle de la version, l'authentification, la sécurité et la gestion de plusieurs demandes ou des données inutiles.

REST API Exemple

Ouvrez le lien suivant dans votre navigateur pour demander un problème d'ordinateur aléatoire de la base de données Open Trivia:

https://www.php.cn/link/bf13848f7f02f488b2e12e009a8b0df3

Il s'agit d'une API publique implémentée en tant que service Web RESTful (il suit la convention de repos). Votre navigateur affichera une seule question de quiz JSON avec des réponses, telles que:

<code>{
  "response_code": 0,
  "results": [
    {
      "category": "Science: Computers",
      "type": "multiple",
      "difficulty": "easy",
      "question": "What does GHz stand for?",
      "correct_answer": "Gigahertz",
      "incorrect_answers": [
        "Gigahotz",
        "Gigahetz",
        "Gigahatz"
      ]
    }
  ]
}</code>

Vous pouvez utiliser n'importe quel client HTTP (comme Curl) pour demander la même URL et obtenir la réponse:

<code>curl "https://www.php.cn/link/bf13848f7f02f488b2e12e009a8b0df3"</code>

Les bibliothèques clients HTTP sont disponibles dans toutes les langues populaires et les environnements d'exécution, y compris Fetch in JavaScript, Node.js et Deno, et file_get_contents() dans PHP. Les réponses JSON sont lisibles par la machine, elles peuvent donc être analysées et utilisées avant de sortir HTML ou d'autres formats.

REST API et autres technologies

Au fil des ans, diverses normes de communication de données ont été développées en continu. Vous avez peut-être rencontré des options comme CORBA, SOAP ou XML-RPC. La plupart ont des règles d'information strictes.

Le repos a été défini en 2000 par Roy Fielding et est beaucoup plus simple que les autres technologies. Ce n'est pas une norme, mais un ensemble de suggestions et de contraintes sur les services Web RESTful. Ceux-ci incluent:

• Client-Server: System A émet une demande HTTP à l'URL hébergée par System B, et System B renvoie une réponse. C'est la même chose que le navigateur fonctionne. Le navigateur demande une URL spécifique. Les demandes sont acheminées vers le serveur Web, qui renvoie généralement les pages HTML. La page peut contenir des références aux images, aux feuilles de style et à JavaScript, ce qui entraînera d'autres demandes et réponses.
• Stateless: REST est sans état: la demande du client doit contenir toutes les informations requises pour la réponse. En d'autres termes, deux demandes HTTP ou plus doivent être faites dans n'importe quel ordre et la même réponse sera reçue (... à moins que l'API ne soit conçue pour renvoyer une réponse aléatoire, comme dans l'exemple de quiz ci-dessus).
• CACHABLE: La réponse doit être définie comme cacheable ou non crampable. La mise en cache améliore les performances car il n'est pas nécessaire de régénérer les réponses pour la même URL. Les données privées pour un utilisateur spécifique à un moment précis ne sont généralement pas mises en cache.
• Hydratation: demander aux clients n'a pas besoin de savoir s'ils communiquent avec le serveur réel, le proxy ou tout autre intermédiaire.

Créer un service Web RESTful

Les demandes de service Web RESTful incluent:

1. URL du point de terminaison. Une application qui implémente l'API RESTful définira un ou plusieurs points de terminaison d'URL, y compris les noms de domaine, les ports, les chemins et / ou les chaînes de requête - par exemple, https://mydomain/user/123?format=json.

2. Méthode HTTP. Différentes méthodes HTTP peuvent être utilisées pour n'importe quel point de terminaison, qui correspondent aux opérations de création, de lecture, de mise à jour et de supprimer (CRUD) de l'application:

   HTTP Méthode crud Opération obtenir lire renvoyer les données demandées Post Créer Créer un nouvel enregistrement Put ou patch metter à jour Mettre à jour les enregistrements existants supprimer supprimer supprimer supprimer les enregistrements existants

   Exemple:
   • /user/
   Obtenir une demande pour
   • revient à la liste des utilisateurs enregistrés sur le système /user/
   Créez un utilisateur avec ID 123 en utilisant les données principales pour la demande de post
   • (voir 4. ci-dessous). La réponse renvoie l'ID. /user/123
   Mettre à jour l'utilisateur 123 à l'aide des données du sujet pour les demandes de put pour
   • (voir 4. ci-dessous) /user/123
   Renvoyez les détails de l'utilisateur 123 lorsque la demande de GET pour
   • /user/123
   Supprimer l'utilisateur 123
   pour supprimer la demande

4. En-tête http. Des informations telles que les jetons ou cookies d'authentification peuvent être inclus dans l'en-tête de demande HTTP.

   <script> fetch('http://localhost:8888/hello/') .then((response) => { return response.json(); }) .then((json) => { console.log(json); }); </script> Données de sujet. Les données sont généralement transmises sur le corps HTTP de la même manière que les engagements HTML, ou en envoyant une seule chaîne de données codée par JSON.

REST API RÉPONSE

La charge utile de réponse peut être n'importe quel contenu pratique: données, HTML, images, fichiers audio, etc. Les réponses des données sont généralement codées en JSON, mais peuvent également être utilisées dans XML, CSV, des chaînes simples ou tout autre format. Vous pouvez vous permettre de spécifier le format de retour dans la demande - par exemple, /user/123?format=json ou /user/123?format=xml.

Le code d'état HTTP approprié doit également être défini dans l'en-tête de réponse. 200 OK est utilisé pour les demandes réussies, bien que 201 créée puisse également être retournée lorsque l'enregistrement est créé. Les erreurs doivent renvoyer les codes appropriés tels que 400 Bad Request, 404 non trouvé, 401 non autorisé, etc.

D'autres en-têtes HTTP, y compris des directives de contrôle du cache ou expirent, peuvent être définis pour spécifier la durée de la mise en cache avant que la réponse ne soit considérée comme "périmée".

Cependant, il n'y a pas de règles strictes. Les URL de point de terminaison, les méthodes HTTP, les données corporelles et les types de réponse peuvent être implémentées en fonction de vos préférences. Par exemple, la publication, le put et le patch sont souvent utilisées de manière interchangeable, donc soit créer ou mettre à jour des enregistrements au besoin.

REST API "Hello World" Exemple

Le code Node.js suivant utilise le framework express pour créer un service Web RESTful. Un seul point final /hello/ répond à une demande de GET HTTP.

Assurez-vous que Node.js est installé et créez un nouveau dossier nommé restapi. Créez un nouveau fichier package.json dans ce dossier, avec le contenu suivant:

<code>{
  "response_code": 0,
  "results": [
    {
      "category": "Science: Computers",
      "type": "multiple",
      "difficulty": "easy",
      "question": "What does GHz stand for?",
      "correct_answer": "Gigahertz",
      "incorrect_answers": [
        "Gigahotz",
        "Gigahetz",
        "Gigahatz"
      ]
    }
  ]
}</code>

Exécutez npm install à partir de la ligne de commande pour obtenir les dépendances et créer un fichier index.js avec le code suivant:

<code>curl "https://www.php.cn/link/bf13848f7f02f488b2e12e009a8b0df3"</code>

Utilisez npm start pour démarrer l'application à partir de la ligne de commande et ouvrir http://localhost:8888/hello/ dans votre navigateur. Le JSON suivant sera affiché en réponse à une demande de GET:

<code>{
  "name": "restapi",
  "version": "1.0.0",
  "description": "REST test",
  "scripts": {
    "start": "node ./index.js"
  },
  "dependencies": {
    "express": "4.18.1"
  }
}</code>

API permet également des noms personnalisés, donc http://localhost:8888/hello/everyone/ return:

<code class="language-javascript">// simple Express.js RESTful API
'use strict';

// initialize
const
  port = 8888,
  express = require('express'),
  app = express();

// /hello/ GET request
app.get('/hello/:name?', (req, res) =>
  res.json(
    { message: `Hello ${req.params.name || 'world'}!` }
  )
);

// start server
app.listen(port, () =>
  console.log(`Server started on port ${port}`);
);</code>

Demande de repos client et CORS

Considérons les pages HTML suivantes lancées avec URL http://localhost:8888/ dans votre navigateur:

<code class="language-json">{
  "message": "Hello world!"
}</code>

L'appel

Fetch effectue la même demande d'API et la console du navigateur affichera Object { message: "Hello world!" } comme vous vous y attendez.

Cependant, supposons que votre service Web RESTful est maintenant en ligne sur le nom de domaine http://mydomain.com/hello/ sur le Web. La page javascript fetch() URL change en conséquence, mais l'ouverture http://localhost:8888/ dans le navigateur renvoie désormais l'erreur de console Cross-Origin Request Blocked.

Pour des raisons de sécurité, le navigateur autorise uniquement le client XMLHTTPREQUEST et Reprochez les appels d'API à héberger dans le même domaine que la page d'appel.

Heureusement, le partage de ressources croisées (CORS) nous permet de contourner cette restriction de sécurité. Paramètres Access-Control-Allow-Origin L'en-tête de réponse HTTP indique au navigateur d'autoriser les demandes. Il peut être défini sur un nom de domaine spécifique ou * (représentant tous les noms de domaine) (comme indiqué dans l'API du quiz ci-dessus).

Le code API du service Web peut être modifié pour permettre l'accès à tout script client qui s'exécute sur n'importe quel nom de domaine:

<code>{
  "response_code": 0,
  "results": [
    {
      "category": "Science: Computers",
      "type": "multiple",
      "difficulty": "easy",
      "question": "What does GHz stand for?",
      "correct_answer": "Gigahertz",
      "incorrect_answers": [
        "Gigahotz",
        "Gigahetz",
        "Gigahatz"
      ]
    }
  ]
}</code>

Alternativement, vous pouvez utiliser la fonction middleware express.js pour fixer l'en-tête à chaque demande de point de terminaison:

<code>curl "https://www.php.cn/link/bf13848f7f02f488b2e12e009a8b0df3"</code>

Veuillez noter que le navigateur fera deux demandes à l'API REST:

1. Une demande d'options HTTP pointant vers la même URL pour déterminer si l'en-tête de réponse HTTP est valide Access-Control-Allow-Origin
Call de repos réel

Lorsque votre serveur reçoit la méthode de demande d'options, il peut définir l'en-tête de réponse

HTTP et renvoyer une réponse vide virtuelle pour s'assurer qu'aucun travail en double n'est effectué. Access-Control-Allow-Origin

REST API Challenge

Le succès de REST est en grande partie dû à sa simplicité. Les développeurs peuvent mettre en œuvre des API RESTful selon leurs préférences, mais cela peut entraîner de nouveaux défis. Pour un aperçu approfondi de nos 13 meilleures pratiques sur la construction d'une API RESTful.

cohérence des points de terminaison

Considérez les points de terminaison suivants:

• /user/123
• /user/id/123
• /user/?id=123

Toutes ces options sont des options valides pour obtenir des données utilisateur 123. Le nombre de combinaisons augmente davantage à mesure que vous effectuez des opérations plus complexes. Par exemple, le retour de dix noms de famille qui commencent par "A" et travaillent dans Companyx, triez dans l'ordre inverse par date de naissance, en commençant par le record 51.

En fin de compte, peu importe la façon dont vous formatez l'URL, mais la cohérence de l'API est très importante. Cela peut être un défi pour une grande base de code avec de nombreux développeurs.

Contrôle de la version API REST

Les modifications de l'API

sont inévitables, mais les URL de point de terminaison ne devraient jamais échouer, sinon ils briseront l'application qui les utilise.

Les API adoptent généralement le contrôle de la version pour éviter les problèmes de compatibilité. Par exemple,

remplace /2.0/user/123. Les points de terminaison nouveaux et anciens peuvent rester actifs. Malheureusement, cela nécessite alors le maintien de plusieurs API historiques. Les versions plus anciennes peuvent éventuellement être rejetées, mais ce processus nécessite une planification minutieuse. /user/123

Authentification de l'API REST

L'API du quiz ci-dessus est

Open : Tout système peut obtenir des blagues sans autorisation. Ce n'est pas possible pour les API qui accèdent aux données privées ou permettent des mises à jour et supprimer les demandes.

Les applications clients qui sont dans le même domaine que l'API RESTful enverront et recevront des cookies comme toute autre demande HTTP. (Notez que Fetch () dans les anciens navigateurs nécessite de définir l'option d'initialisation

.) Par conséquent, la demande d'API peut être vérifiée pour s'assurer que l'utilisateur est connecté et a les autorisations appropriées. credentials

Une application tierce doit utiliser d'autres méthodes d'authentification. Les options d'authentification courantes incluent:

• HTTP Authentification de base. Passez l'en-tête d'autorisation HTTP contenant le codage Base64 dans l'en-tête de demande.
Clé API
• . Accordez l'autorisation des demandes de tiers pour utiliser l'API en émettant des clés qui peuvent avoir des autorisations spécifiques ou limitées à un domaine spécifique uniquement. La clé est passée dans chaque demande de l'en-tête HTTP ou de la chaîne de requête.
• oauth. Avant toute demande, le jeton doit être obtenu en envoyant l'ID client et la clé du client possible au serveur OAuth. Le jeton OAuth sera ensuite envoyé avec chaque demande d'API jusqu'à ce qu'il expire.
• JSON Web Token (JWT). Les jetons d'authentification signés numériquement sont en toute sécurité transmis dans les en-têtes de demande et de réponse. JWT permet au serveur de coder les autorisations d'accès, il n'est donc pas nécessaire d'appeler une base de données ou un autre système autorisé.

L'authentification de l'API variera en fonction de l'environnement d'utilisation:

• Dans certains cas, une application tierce sera considérée comme tout autre utilisateur connecté avec des autorisations spécifiques. Par exemple, l'API MAP peut renvoyer un itinéraire entre deux points vers l'application d'appel. Il doit confirmer que l'application est un client valide, mais n'a pas besoin de vérifier les informations d'identification de l'utilisateur.
• Dans d'autres cas, les applications tierces demandent des données privées appartenant à un seul utilisateur, telles que le contenu par e-mail. L'API REST doit identifier l'utilisateur et ses autorisations, mais il peut ne pas se soucier de quelle application appelle l'API.

REST API Sécurité

L'API RESTFul fournit une autre façon d'accéder et de faire fonctionner les applications. Même s'il ne s'agit pas d'une cible de pirates hautement regardée, un client mal comporté peut envoyer des milliers de demandes par seconde et écraser votre serveur.

La sécurité n'est pas dans le cadre de cet article, mais les meilleures pratiques courantes incluent:

• en utilisant https
• Utilisez de puissantes méthodes d'authentification
• Utilisez des COR pour limiter les appels clients à des domaines spécifiques
• fournit une fonctionnalité minimale - c'est-à-dire ne pas créer des options de suppression indésirables
• Vérifiez toutes les URL de point de terminaison et les données principales
• Évitez d'exposer les jetons d'API dans le client javascript
• Bloquer l'accès à partir de domaines inconnus ou d'adresses IP
• Arrêtez de grosses charges utiles inattendues
• Considérez les limites de taux - c'est-à-dire que les demandes utilisant le même jeton API ou l'adresse IP sont limitées à N par minute
• Répondez avec le code d'état HTTP approprié et l'en-tête de cache
• Enregistrer les demandes et enquêter sur les échecs

Demandes multiples et données inutiles

L'API RESTful est limitée par son implémentation. La réponse peut contenir plus de données que vous avez besoin, ou des demandes supplémentaires sont nécessaires pour accéder à toutes les données.

Considérons une API RESTful qui donne accès aux données d'auteur et de livre. Pour afficher les données des dix meilleurs best-sellers, le client peut:

• Demandez le top 10 par quantité de vente (les meilleurs vendeurs préférés) /book/ Détails. La réponse contient une liste de livres avec chaque ID d'auteur.
• Envoyez jusqu'à 10 /author/{id} demandes d'obtention d'informations détaillées pour chaque auteur.

Ceci est appelé un problème N 1;

S'il s'agit d'un cas d'utilisation courant, vous pouvez modifier l'API RESTful afin que chaque livre retourné contient des détails complets de l'auteur tels que leur nom, leur âge, leur pays, sa biographie, etc. Il peut même fournir tous les détails de ses autres livres - bien que cela puisse augmenter considérablement la charge utile de réponse!

Pour éviter de grandes réponses inutiles, l'API peut être ajustée pour rendre les détails de l'auteur en option - par exemple, ?author_details=full. Le nombre d'options auxquelles les auteurs d'API doivent gérer peuvent être éblouissants.

GraphQL peut-il résoudre le problème de l'API REST?

Rest Puzzle a LED Facebook pour créer GraphQL, un langage de requête de service Web. Considérez-le comme un service Web SQL: une seule demande définit les données dont vous avez besoin et comment vous souhaitez les retourner.

GraphQL résout certains des défis présentés par l'API RESTFul, bien qu'il en présente d'autres. Par exemple, la mise en cache des réponses GraphQL devient difficile.

Votre client est peu susceptible d'avoir un problème similaire avec Facebook, il peut donc être utile de considérer GraphQL après que l'API RESTful ait dépassé sa limite réelle.

REST LIENS API et outils de développement

Il existe de nombreux outils dans toutes les langues qui peuvent aider au développement d'API RESTful. Les options notables incluent:

• Swagger: Divers outils qui aident à concevoir, enregistrer, simuler, tester et surveiller les API REST
• Postman: application de test API RESTFul
• HOPPSCOTCH: Open source de Postman, alternative Web

Il existe également de nombreuses API de repos public pour les blagues, les conversions de devises, les géocodes, les données gouvernementales et chaque sujet auquel vous pouvez penser. Beaucoup sont gratuits, bien que certains vous obligent à enregistrer une clé API ou à utiliser d'autres méthodes d'authentification. La liste des catégories comprend:

• Toute API
• Liste des API
• API publiques
• Google API Explorer

Avant d'implémenter votre propre service Web, essayez d'utiliser une API RESTful dans votre propre projet. Ou, vous pouvez suivre Facebook, Github, Google et de nombreux autres géants pour construire votre propre API RESTful.

Les questions fréquemment posées sur l'API REST

Qu'est-ce que l'API REST?

API REST (Interface de programmation d'application de transfert d'état détaillée) est un ensemble de règles et de conventions qui permettent aux applications logicielles de communiquer et d'interagir entre elles sur Internet en utilisant les principes du style architectural REST.

Quelles sont les principales caractéristiques de l'API REST? L'API REST est caractérisée par l'utilisation des ressources, la communication client-serveur sans état, les méthodes HTTP standard (obtenir, publier, mettre, supprimer) et les interfaces unifiées qui impliquent généralement l'accès et la manipulation des ressources à l'aide d'URL.

Pourquoi s'appelle-t-il API REST?

L'API REST (interface de programmation d'application de transport d'état détaillée) est nommée d'après le style architectural qu'il suit, appelé REST (transport d'état détaillé). Le terme «repos» a été proposé par Roy Fielding dans sa thèse de doctorat de 2000, dans laquelle il a décrit les principes et les contraintes de ce style architectural. Le nom "REST" représente le concept de transfert d'une représentation de l'état des ressources du serveur vers le client.

Quels sont les avantages de l'utilisation de l'API REST? L'API REST offre de nombreux avantages, notamment la simplicité, l'évolutivité, la facilité d'intégration, l'indépendance de la plate-forme et la séparation des préoccupations. Ils tirent également parti de l'infrastructure HTTP existante, ce qui est idéal pour les applications Web et mobiles.

L'API REST est-elle limitée aux applications Web? Non, l'API REST n'est pas limitée aux applications Web. Ils peuvent être utilisés pour faciliter la communication entre les différents types d'applications logicielles, y compris les applications Web, les applications mobiles et même la communication de serveur à serveur.

Quelles sont les quatre composantes de l'API REST?

L'API REST se compose de quatre composantes principales, communément appelées "quatre piliers" de repos. Ces composants aident à définir la structure, le comportement et l'interaction des API dans le style architectural de repos. Les quatre composants sont des ressources, des méthodes HTTP (verbes), des représentations et des interfaces générales.

Quels outils ou bibliothèques puis-je utiliser pour construire l'API REST? Il existe de nombreux outils et frameworks pour construire des API REST, notamment Express.js (Node.js), Flask (Python), Ruby on Rails (Ruby), Django (Python), Spring Boot (Java), et plus encore.

Cette réponse maintient le formatage et le placement d'image d'origine.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!