L'échange de données entre plusieurs plateformes est plus crucial que jamais à l'ère des intégrations. Imaginez une boutique en ligne sans intégrations. Votre site Web devrait développer des systèmes pour gérer les comptes d'utilisateurs, les abonnements aux courriels, le traitement des paiements, les expéditions et d'autres tâches, en plus de la gestion des listes de produits. Il serait plus efficace de confier ces tâches à d'autres fournisseurs, car il ne s'agit pas d'une option évolutive.
Lesinterfaces de programmation d'applications, ou API web, sont ce que les programmes logiciels utilisent pour communiquer entre eux. Les API offrent un protocole cohérent pour l'échange de données entre deux programmes. Grâce aux API Web, votre boutique en ligne peut communiquer avec les logiciels de livraison, les applications client, les applications de paiement et toute autre connexion requise.
Il existe plusieurs façons de créer une API ; toutefois, si vous souhaitez ajouter des connexions logicielles à vos services, il existe une technique unique que vous devez connaître : Les services Web des API REST. Dans cet article, nous aborderons les exemples d'API REST, ce qu'est une API REST, son fonctionnement, son utilisation, son historique, ses éléments, etc.
Qu'est-ce qu'une API REST exactement ?
Les services Web des API REST (Representational State Transfer) constituent la pratique la plus courante pour relier les composants dans les cadres de microservices, car ils offrent un moyen polyvalent et portable d'intégrer des applications. REST est une conception d'API populaire que nous employons pour interagir avec les parties prenantes internes et externes d'une manière normalisée et prévisible.
Les utilisateurs d'applications web utilisent fréquemment les services web des API REST pour communiquer entre eux. Par exemple, l'acquisition et l'examen des détails d'un compte dans un programme de médias sociaux. Les navigateurs REST APIs peuvent être considérés comme la syntaxe du web. Les clients en ligne utilisent les API Web pour fournir et gérer l'accès aux opérations numériques à mesure que l'utilisation du cloud augmente.
La conception d'API Web permettant aux clients de se connecter à des services Web numériques, de les administrer et de s'y engager de manière dynamique dans un contexte dispersé est une décision judicieuse. Des sites Web comme Google, eBay, Facebook, Amazon et Twitter utilisent des services Web RESTful. Les applications clientes peuvent désormais utiliser REST pour accéder à ces services web.
La technologie REST est privilégiée par rapport à d'autres technologies connexes. En effet, les services web REST consomment moins de bande passante, ce qui les rend idéaux pour une activité en ligne efficient. Les services web RESTful peuvent également être développés à l'aide de langages de programmation tels que JavaScript ou Python.
Comment fonctionnent les API REST ?
Pour savoir comment fonctionnent les API REST, nous devons définir certains termes clés :
Client
Un utilisateur d'API est appelé client. Le client envoie des requêtes aux API Web pour obtenir des données ou appliquer des modifications au programme. Votre navigateur Internet est un client ; il communique avec diverses API Web pour obtenir le contenu des pages. Votre ordinateur reçoit les informations requises, qui s'affichent ensuite à l'écran.
Voici les méthodes HTTP les plus courantes :
- Utilisez la requête GET pour renvoyer les données demandées ou les ressources demandées.
- Utilisez la requête POST pour créer une nouvelle ressource.
- Utilisez l'instruction PUT pour apporter des modifications à une ressource existante ou continuer à la mettre à jour
- Utiliser l'instruction DELETE pour se débarrasser d'une ressource.
Par exemple, une demande HTTP à l'API de Youtube pourrait être une ressource de demande GET pour une vidéo ou un post particulier ou une demande POST pour publier une nouvelle photo. Vous pouvez utiliser la méthode de requête POST pour publier de nouveaux posts. De même, une plate-forme de services Web pour les clients qui s'intègre à une mise en œuvre de la fonction d'accueil automatique peut employer l'instruction PUT pour mettre à jour ou supprimer un accueil personnalisé.
Demande Get
- La mise en cache des requêtes GET est possible. L'historique du navigateur inclut les requêtes GET.
- Il est possible de créer des signets pour les demandes GET.
- N'utilisez jamais les requêtes GET lorsque vous travaillez avec du matériel critique.
- Les requêtes GET sont limitées en longueur.
- Seules les requêtes de données sont effectuées via des requêtes GET.
La méthode POST
La requête POST est une méthode permettant d'envoyer des informations à un serveur pour ajouter ou mettre à jour des ressources. Le corps d'une requête HTTP contient les données qui sont publiées du côté du serveur :
- Les requêtes POST post method ne vont jamais dans un cache.
- Les requêtes POST ne sont pas stockées dans l'historique du navigateur.
- Les requêtes POST ne peuvent pas être mises en signet
Corps de la réponse
Le corps de la réponse est l'un des éléments importants de l'API RESTful. Les données demandées sont incluses dans le corps de la réponse. Le corps de réponse peut inclure des données relatives aux ports logiques de sortie et de sortie.
Ressource
Toute donnée que les API Web peuvent fournir à l'utilisateur est une ressource. Par exemple, un individu, une page, une image ou une remarque peuvent tous être considérés comme des ressources dans l'API Facebook. L'identifiant de ressource est un terme spécial donné à chaque ressource.
Serveur web
Le programme qui accepte le corps de la demande du client utilise un serveur Web, qui héberge les ressources demandées par le consommateur. Le serveur peut communiquer avec les clients par le biais d'une API sans offrir aux clients un accès immédiat aux informations conservées dans ses bases de données. Lorsqu'un utilisateur accède aux services web RESTful pour soumettre un corps de demande, le serveur envoie une représentation normalisée de l'état de la ressource au navigateur.
Cela signifie que le serveur ne soumet pas la ressource exacte au client mais reflète plutôt son état, c'est-à-dire la situation de la ressource à un moment précis. Pour faciliter la compréhension, les réponses sont renvoyées dans un format léger.
Le format JSON (JavaScript Object Notation) est largement utilisé car il est lisible à la fois par les personnes et par les machines et il excelle dans la promotion de l'accessibilité du web. JSON est principalement utilisé pour envoyer le corps de la requête dans les applications web et les applications clientes. C'est une forme compatible avec une variété de codage. Les formats de données d'API autres que JSON comprennent XML, YAML, CSV, HTML et le texte brut. Les utilisateurs d'API peuvent choisir le format de données qu'ils souhaitent en utilisant des types de médias personnalisés.
Histoire des API REST
De nombreux programmeurs ont dû travailler avec SOAP avant que REST n'intègre les API. La construction, l'utilisation et le débogage de SOAP étaient des tâches notoirement difficiles. Heureusement, REST a été développé par une équipe de programmeurs sous la direction de Roy Fielding, modifiant à jamais l'environnement des API.
Voici une chronologie du développement des API REST au fil du temps :
Avant REST
Les programmeurs écrivaient manuellement un fichier XML contenant un appel de procédure à distance (RPC) à l'intérieur du contenu pour connecter les API Web à l'aide de SOAP. Ensuite, les concepteurs envoyaient leur paquet SOAP au point de terminaison spécifié.
En l'an 2000
Une équipe de programmeurs dirigée par Roy Fielding a choisi de développer un cadre permettant à tout serveur de communiquer avec tout autre serveur. Il a établi les restrictions pour les API REST. Comme ces directives sont universelles, le développement de logiciels est plus facile.
En 2002
eBay a développé son API RESTful en 2002, ouvrant sa place de marché à tout site web susceptible d'en bénéficier. C'est pourquoi un autre titan du commerce électronique, Amazon, s'y est intéressé et a publié son API RESTful en 2002.
Dans les années 2004-2006
Les services web RESTful de Flickr ont été publiés en 2004, permettant aux rédacteurs d'ajouter rapidement des photographies à leurs sites web et à leurs publications sur les médias sociaux. Lorsque Twitter et Facebook ont remarqué qu'un nombre important de programmeurs analysaient les sites web et créaient des API "Frankenstein", ils ont tous deux exposé leurs API environ deux ans plus tard.
De 2006 à aujourd'hui
Les services web RESTful sont désormais largement acceptés par les programmeurs, qui les utilisent pour améliorer les performances de leurs applications et sites. AppMaster facilite la coopération et rend plus facile la construction d'APIs, vous permettant de le faire plus rapidement.
À quoi servent les API REST ?
L'un des principaux avantages des services web RESTful est qu'ils offrent une grande flexibilité, vous permettant d'utiliser cette API RESTful plus efficacement. Vous trouverez ci-dessous quelques exemples d'API REST pour lesquelles elles sont utilisées.
Applications basées sur le cloud
En raison de l'apatridie de ses appels, les API REST sont avantageuses dans les applications en nuage. Les modules apatrides peuvent facilement être réinstallés et se développer pour répondre aux besoins de capacité en cas de problème. Un programme logiciel combinant des composants locaux et basés sur Internet est une application en nuage. Ce paradigme utilise des serveurs distants auxquels on accède par un navigateur Web et des services Web Internet permanents pour exécuter des instructions.
L'emplacement traditionnel des hôtes d'applications en nuage est un système informatique distant géré par un opérateur de réseau informatique en nuage tiers. La messagerie, le partage et le stockage de documents, la saisie de commandes, le contrôle des stocks, Microsoft Word, la gestion des relations avec la clientèle(CRM), la collecte d'informations, les finances et la comptabilité sont des exemples de tâches effectuées à l'aide d'applications en nuage.
Les interfaces de programmation d'applications(API) REST peuvent être utilisées pour connecter des sources externes d'informations et de ressources de stockage. Les programmeurs peuvent rendre les applications en nuage plus petites en utilisant les API REST pour transférer des données à d'autres programmes afin de traiter ou d'analyser des calculs et de renvoyer les résultats au programme logiciel. Des API testées renforcent l'uniformité active, ce qui peut accélérer la production et produire des résultats réels.
Google Docs ou Office 365 constituent un excellent exemple d'application en nuage. Tout ce dont vous avez besoin pour Google Docs ou Office 365 est un ordinateur capable d'exécuter des moteurs de recherche et des services web sur Internet. Les réseaux informatiques fournissent l'interface utilisateur et les opérations, y compris le stockage des informations. De nombreuses applications en nuage distinctes peuvent être hébergées par votre entreprise en utilisant des hôtes d'applications en nuage.
Services en nuage
Étant donné que vous devrez gérer le traitement de l'URL pour vous connecter à une ressource via une API, les API REST sont également utiles pour les services Web en nuage. L'architecture des services Web RESTful deviendra probablement la norme à l'avenir en raison des applications en nuage. Les programmeurs utilisent les services web RESTful pour se connecter aux services en nuage en utilisant l'internet. Un développeur crée un code qui utilise l'API du fournisseur d'accès à Internet, fournit les entrées et les variables nécessaires, puis vérifie la réponse pour s'assurer que l'action fonctionne comme prévu.
Les utilisateurs finaux peuvent accéder aux applications clientes ou aux services web offerts par les services en nuage, tels que l'infrastructure de calcul, les systèmes de stockage ou les systèmes de suivi, en utilisant un service en nuage comme les services web RESTful. Les API décrivent les capacités et les opérations d'une application ainsi que les spécificités requises pour les exécuter. Pour préserver la confidentialité et la sécurité des clients, les API dépendent souvent de l'interopérabilité REST ou SOAP (Simple Object Access Protocol) et de mécanismes d'autorisation comme OAuth 2.0.
Une variété de services web sont appelés "services en nuage" et sont mis à la disposition des entreprises et des consommateurs en ligne sur demande. Ces services web sont créés pour offrir un accès rapide et peu coûteux à des outils et à des applications sans nécessiter de matériel ou d'infrastructure. La plupart des employés utilisent les services web en nuage pour tout, du courrier électronique à la collaboration documentaire.
Utilisation du Web
Ces API Web peuvent être obtenues à partir d'un projet Web de l'utilisateur, d'une application iPhone, d'un appareil IoT ou d'un Windows Mobile puisque REST ne dépend pas de la fonctionnalité côté client. Vous pouvez créer l'architecture de votre entreprise sans être contraint à un cadre spécifique côté client.
Un exemple d'API REST
Voyons un exemple d'API REST. Cliquez sur le lien ci-dessous pour poser une question arbitraire à la base de données Open Trivia : De tels services Web REST ont été utilisés pour fournir une API Web publique. Votre ordinateur affichera une question de quiz solitaire et ses réponses au format JSON.
À l'aide de n'importe quel navigateur HTTP, comme url, vous pouvez émettre la requête suivante et recevoir une réponse dans le corps de réponse : https://opentdb.com/api.php?amount=1&category=18.
Le corps de réponse du fichier XML du service Web contiendra toutes les informations relatives à l'employé.
Tous les dialectes de programmation et outils de développement largement utilisés disposent de bibliothèques de clients HTTP, comme retrieve en JavaScript, Node.js et Deno et file get contents() en PHP. Une réponse JSON peut être lue et utilisée car elle est lisible par machine avant d'être affichée en HTML ou dans un autre style.
Les API Rest et REST
Au fil du temps, de nombreuses méthodes de transmission de données se sont développées. Vous avez peut-être rencontré des choix comme CORBA, SOAP ou XML-RPC. La plupart ont développé des directives strictes pour les messages. Roy Fielding a présenté pour la première fois REST en 2000, qui est beaucoup plus simple que les autres.
Il s'agit d'une collection de suggestions et de limitations pour les services web REST plutôt que d'une norme. Il s'agit des contraintes architecturales suivantes :
Partition client-serveur
Les clients et les serveurs web ne peuvent communiquer que dans un seul sens sous l'architecture REST : le client demande le contrôleur de domaine, et le contrôleur ou le serveur répond à la demande. Les serveurs web sont incapables de soumettre des demandes, et les clients ne peuvent pas réagir ; le consommateur lance toutes les connexions.
Les services Web RESTful maintiennent les clients et les serveurs isolés en facilitant l'interaction entre eux. Les clients peuvent se développer sans craindre d'avoir un impact sur un autre hébergement, et le matériel des serveurs peut être modifié sans avoir un impact involontaire sur les clients.
Interface uniforme
Selon cette stratégie, toutes les requêtes et réactions doivent respecter une procédure proweb standard ou styliser leurs messages. Les applications et les serveurs sont développés dans divers langages de programmation qui fonctionnent mal entre eux avec un médiateur. Une interface uniforme est un dialecte que tout client peut utiliser pour interagir avec n'importe quelle API REST.
La traduction des demandes et des réactions entre les applications ne serait possible qu'avec une interaction normalisée. Des différences mineures entraîneraient un désordre et une perte d'informations, et les solutions devront mettre à jour leurs procédures de demande lorsque les API Web modifieront les leurs. Une interface normalisée élimine cette perspective.
ACCÉDER À https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Comme toutes les applications client REST, cette proposition comprend deux éléments de données. La technique HTTP est GET. Elle décrit l'action que le client souhaite effectuer sur les ressources. Un utilisateur peut effectuer quatre méthodes HTTP de base :
HTTP, ou Hyper-Text Transfer Protocol, est le langage universel de la plupart des API REST. HTTP n'a pas été conçu dans l'optique de REST. En outre, REST a accepté cette transmission de données comme critère pour les applications compatibles avec REST. Pour utiliser HTTP avec les API REST, le client soumet une requête dans un format que vous connaissez peut-être. Une demande de signal vidéo à l'API YouTube, par exemple, ressemble à ceci :
- Utilisez la commande GET pour obtenir une ressource.
- Utilisez la commande POST pour créer une nouvelle ressource.
- Utilisez la commande PUT pour modifier ou continuer à mettre à jour une ressource existante
- Utilisez la commande DELETE pour vous débarrasser d'une ressource.
Les méthodes HTTP spécifient l'action à entreprendre concernant une ressource spécifique. Les méthodes HTTP sont également connues sous le nom de verbes HTTB.
L'URL est HTTP
L'identifiant de ressource uniforme, ou URI, qui identifie la ressource visée est contenu dans l'URL. L'URL est également un point de terminaison dans ce scénario, car c'est là que l'API RESTful entre en contact avec l'utilisateur du service.
Chaîne d'interrogation : L'URL comprend une chaîne de requête. La chaîne de requête est utilisée pour définir les paramètres, auxquels sont attribuées des valeurs.
Après avoir reçu et vérifié le plaidoyer, le serveur web renvoie les données sur la ressource ciblée. Généralement, les données sont renvoyées dans une structure connue sous le nom de JSON (JavaScript Object Notation). JSON présente tous les composants d'une ressource dans un format portable que les humains peuvent facilement lire.
Principes de l'interface uniforme
L'interface uniforme doit respecter les paramètres suivants :
HATEOAS : L'hypermédia comme moteur de l'état d'application
L'hypermédia est le moteur des services web RESTful. Cela indique que l'hypermédia est tout ce que le client veut comprendre pour reconnaître la réponse du fournisseur.
- Seule la première URI de l'application client doit être fournie au client. L'application client doit piloter en permanence tous les autres matériels et activités à l'aide d'hyperliens.
- Les services web RESTful ne nécessitent pas de langage de requête d'entrée (IDL), ce qui les différencie des autres API.
Un type de média est un nom pour le format de données d'une représentation. Le type de média identifie une définition qui décrit comment une représentation doit être traitée. Une API web qui utilise REST ressemble à un hypertexte. Chaque élément de données qui peut être adressé porte un emplacement, soit directement (comme par le biais des propriétés de lien et d'identité), soit implicitement (par exemple, dérivé de la structure de description du type de média).
Messages autodescriptifs
Chaque communication entre le côté client et le côté serveur doit fournir suffisamment de données pour exécuter la communication. En conséquence, la requête du client vers le serveur doit spécifier la ressource à laquelle il tente d'accéder ainsi que ses objectifs spécifiques.
En outre, les représentations des ressources doivent être autodescriptives ; l'utilisateur n'a pas à savoir si une ressource est une personne ou un équipement. Au lieu de cela, il doit répondre en suivant le type de média lié à l'aide.
Par conséquent, nous développerons indiscutablement de nombreux types de médias uniques, souvent un type de média par ressource. Chaque forme de média spécifie un paradigme de production standard. Par exemple, le langage HTML définit la façon dont l'hypertexte est présenté et comment le navigateur traite chaque composant.Identifier les ressources
Les ressources auxquelles il est fait référence dans les communications arrière entre le client et le serveur doivent être reconnaissables à l'aide de représentations. S'en tenir au système des identificateurs de ressources uniformes (URI) a permis cela. En d'autres termes, la communication entre le serveur et le client peut inclure une version HTML du document et certaines informations plutôt que le véritable fichier stocké sur le serveur.
Le consommateur peut facilement comprendre la version HTML car elle suit le modèle URI. Le client doit modifier les ressources en donnant au serveur une représentation de la façon dont la ressource devrait finalement apparaître. L'utilisateur pourra ainsi construire, récupérer, modifier et supprimer des ressources. Si le client dispose de l'autorisation nécessaire pour modifier les données, le serveur doit répondre à la requête.
Start FreeTry AppMaster no-code today!Platform can build any web, mobile or backend application 10x faster and 3x cheaper
Apatride
Avec une API RESTful, toutes les demandes des clients doivent être transitoires. Par conséquent, chaque requête et le corps de la réponse comprennent toutes les données nécessaires pour conclure le contrat, ce qui rend chaque connexion autonome. Le serveur ne garde pas trace des requêtes HTTP précédentes ; il traite chacune d'elles comme une requête entièrement nouvelle.
Étant donné que le serveur n'a pas à effectuer de tâches supplémentaires pour obtenir des données historiques, les transports sans état minimisent considérablement la quantité de stockage nécessaire pour le serveur et augmentent la probabilité qu'une réponse soit acceptable. Cela garantit l'évolutivité de ces interactions : les programmeurs n'ont pas à se soucier d'utiliser beaucoup plus de stockage ou de taxer le serveur lorsque leur logiciel s'étend et effectue des requêtes HTTP.
Superposition de
Jusqu'à présent, nous avons défini les requêtes d'API Web comme un simple échange client-serveur, bien que cela soit un peu trop simpliste. Entre ces deux organisations, il y a souvent plus de serveurs. Ces plateformes, ou couches, sont en place pour gérer et disperser le trafic, ajouter une protection et effectuer diverses autres tâches cruciales.
Selon ce concept, les messages envoyés entre un utilisateur et un serveur cible doivent être structurés et traités de manière similaire, quelles que soient les couches qui existent entre eux. Les couches supplémentaires ne devraient pas avoir de conséquences sur les interactions avec les clients. Les programmeurs qui adhèrent à cette règle peuvent changer de système de serveur sans affecter le processus fondamental de demande-réponse.
Mise en cache
La mise en cache se produit lorsqu'un client navigue sur un site Web et que le contenu est enregistré sur sa machine. Le matériel mis en cache est rapidement chargé à partir de la mémoire interne plutôt que d'être téléchargé à nouveau à partir du serveur lorsqu'un utilisateur visite ce site ultérieurement. La plupart des grands sites utilisent la mise en cache pour réduire la charge des pages tout en conservant l'espace du serveur et la bande passante.
La mise en cache des données est prise en compte lors du développement des API REST. La réponse qu'un serveur donne à un client doit indiquer si la ressource donnée peut être stockée et pendant combien de temps.
Code à la demande
Le dernier principe REST est inutile. Si elle est demandée, la réponse d'une API peut inclure du code logiciel à utiliser par les clients. De ce fait, le client peut exécuter l'application ou le programme du client dans son backend.
Une API est considérée comme une API RESTful si elle est conforme à cet ensemble de directives. Ces directives laissent toutefois aux programmeurs une grande liberté pour modifier les caractéristiques de leur API RESTful. Les API REST diffèrent du Simple Object Access Protocol, une autre technique d'API web populaire, en ce qu'elles sont plus flexibles (SOAP).
Consensus sur les points de terminaison
Prenez en compte ces points d'extrémité :
- /user/123\s
- /utilisateur/id/123\s
- /user/123\s/user/id/123\s
- /user/?id=123
Toutes ces méthodes sont légitimes pour permettre au client 123 de récupérer des données. Lorsqu'il existe des procédures plus complexes, le nombre de possibilités augmente. Par exemple, en ordre inverse à partir de l'entrée 51, afficher 10 personnes dont le nom de famille commence par "A" et qui travaillent pour l'entreprise.
En fin de compte, la façon dont vous structurez les URL n'a pas d'importance ; c'est l'uniformité dans l'ensemble de votre API RESTful qui compte. Sur d'énormes systèmes logiciels avec de nombreux programmeurs, cela ne peut pas être facile. Les modifications des API RESTful sont inévitables, mais les URL des points de terminaison ne doivent jamais être rejetées, car cela entraînerait l'arrêt du fonctionnement des applications qui en dépendent.
Versionnement des API REST
Le versionnement des API est une pratique courante pour éviter les incompatibilités. À titre d'exemple, /2.0/user/123 remplace /user/123. L'ancien et le nouveau point de terminaison peuvent tous deux continuer à fonctionner. Par conséquent, cela oblige à maintenir les anciennes API importantes. Les versions antérieures peuvent finalement être retirées, mais la procédure doit être soigneusement étudiée.
Authentification de l'API REST
Tout appareil peut télécharger un quip sans autorisation à l'aide de l'API de requête. Les API qui lisent des informations privées ou qui permettent de modifier et de supprimer des requêtes ne le permettent pas. Les programmes côté client situés dans le même domaine que les services web RESTful sont envoyés et reçoivent des cookies de la même manière que les requêtes HTTP. (Veuillez noter que l'option de redémarrage des privilèges doit être spécifiée dans les sites précédents pour Fetch()). Une requête d'API peut être vérifiée pour confirmer qu'un utilisateur est connecté et dispose des autorisations requises.
Authentification de base HTTP: Les programmes tiers doivent utiliser des solutions d'autorisation différentes. Certaines méthodes d'authentification populaires sont la vérification primaire pour :
- HTTP. Une chaîne nom d'utilisateur : mot de passe codée en base64 est donnée dans le champ de la requête dans le cadre d'un en-tête HTTP Approval.
- Les clés d'API : En fournissant une clé API RESTful qui peut avoir des autorisations spéciales ou être limitée à un seul site, une API est mise à la disposition d'applications tierces. Chaque message contient la clé soit dans la chaîne de requête, soit dans l'en-tête HTTP. (La chaîne de requête est un composant de l'URL).
- OAuth : avant d'effectuer toute demande, un identifiant client et éventuellement un secret client sont envoyés à un serveur OAuth pour obtenir une créance. Jusqu'à son expiration, l'identité OAuth est ensuite transmise avec chaque demande d'API.
- Jetons Internet en JSON (JWT) : L'en-tête de la requête et l'en-tête de la réponse transmettent en toute sécurité les justificatifs d'identité de l'utilisateur signés numériquement. Les JWT permettent au serveur de chiffrer les privilèges d'accès, éliminant ainsi la nécessité d'interroger une base de données ou d'utiliser un autre mécanisme d'authentification.
Le scénario d'utilisation affectera la manière dont une API est authentifiée :
- Parfois, un programme tiers est traité comme tout autre client connecté avec les mêmes privilèges et droits. Par exemple, une API de carte peut fournir à un programme demandeur des instructions entre deux points. Elle doit vérifier que le programme est un utilisateur légitime, mais elle n'a pas à vérifier les informations d'identification du client.
- Dans d'autres situations, le programme tiers demande des informations personnelles à un utilisateur spécifique, comme le contenu d'un courrier. Les API REST doivent reconnaître le client et ses autorisations, mais elles ne doivent pas se préoccuper du programme appelant.
Sécurité des API REST
Les services Web RESTful ajoutent un moyen supplémentaire d'interagir avec votre logiciel et de l'influencer. Même si votre hôte n'est pas un objectif de piratage élevé, un utilisateur mal intentionné pourrait soumettre des centaines de requêtes par seconde et l'effondrer. Cet article ne traite pas de la sécurité, mais les meilleures procédures standard en font partie :
l'utilisation de HTTPS
Utiliser un mécanisme d'authentification forte
Les CORS peuvent être utilisés pour restreindre les appels des clients à des zones particulières.
Fournir les capacités nécessaires, c'est-à-dire ne pas
Générer des choix DELETE qui ne sont pas nécessaires ; vérifier toutes les URL de point de terminaison et les informations du corps.
Bloquez les liens provenant de secteurs ou d'adresses IP non identifiés en ne soumettant pas les bons d'API dans le JavaScript côté client.
Les paquets anormalement volumineux sont bloqués.
Pensez à la restriction de débit, où les demandes provenant de la même adresse IP ou du même justificatif d'API sont limitées à N requêtes par minute.
Réponse avec le bon code d'état HTTP, interrogations du journal de l'en-tête de cache et enquête infructueuse.
Requêtes multiples et données inutiles
Le déploiement de services web RESTful a ses limites. Il est possible qu'une réponse contienne plus d'informations que celles que vous avez demandées ou que plusieurs requêtes soient nécessaires pour obtenir toutes les informations. Pensez aux services web RESTful qui donnent aux utilisateurs l'accès aux informations sur les créateurs et les livres ; le client pourrait :
- Demander les informations sur les 10 premiers livres, classés par ordre d'achat (le meilleur vendeur en premier). Une collection de livres, ainsi que l'ID de chaque auteur, est incluse dans la réponse.
Pour récupérer les informations de chaque auteur, construisez jusqu'à 10 requêtes /author/id.
N requêtes API doivent être générées pour chaque réponse à la requête parent, ce qui constitue le "problème N+1".
S'il s'agit d'une situation d'utilisation fréquente, le service Web RESTfulpourraient être modifiées afin d'inclure toutes les informations sur l'écrivain pour chaque livre qu'elles ont produit, y compris le nom, le sexe, la nationalité, la biographie, etc. Il est possible de fournir encore plus d'informations sur leurs livres précédents, mais cela augmenterait considérablement la charge de réponse. L'API peut être modifiée pour rendre les informations sur l'auteur facultatives. Détails sur l'auteur=full pour éviter les réponses inutilement volumineuses. Le nombre d'options que les concepteurs d'API doivent prendre en charge pourrait être écrasant.
Conclusion
Vous avez maintenant une connaissance approfondie des API REST, de leur fonctionnement, des exemples d'API REST, de leur utilisation, des contraintes architecturales et des autres sujets abordés dans ce tutoriel. Les programmeurs peuvent trouver l'apprentissage des API difficile et intimidant, mais la plateforme no-code AppMaster a créé une nouvelle bibliothèque d'API REST accessible où vous pouvez approfondir votre connaissance d'une gamme d'API REST pour soutenir votre développement professionnel.
Chez AppMaster, nous nous efforçons d'accroître l'accessibilité et la convivialité des API. Nous voulons que vous appreniez, expérimentiez et réalisiez les avantages de l'utilisation des API dans votre carrière et votre vie personnelle. Pour vous aider à concevoir plus rapidement de meilleures API Web, AppMaster améliore la collaboration et automatise chaque étape du cycle de vie des API. Continuez à créer, à faire progresser et à élargir votre compréhension des API REST.
