REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples
1.0.0
REST est acronyme pour le transfert d'état de représentation . L'API RESTFul est un style architectural pour une interface de programme d'application (API) qui utilise des demandes HTTP pour accéder et modifier les données. Ces données peuvent être utilisées pour obtenir, mettre, publier et supprimer des types de données, qui se réfèrent à la lecture, à la mise à jour, à la création et à la suppression des opérations concernant les ressources. Pour plus de détails
Les principales fonctions utilisées dans toute architecture basée sur REST sont:
Votre demande doit satisfaire certaines contraintes ou principes. Passons aux détails de ces principes.
Il y a six principes au sol, ci-dessous les six principes directeurs du repos:
Emportable: les demandes envoyées d'un client au serveur contient toutes les informations nécessaires nécessaires pour les comprendre complètement. Cela peut faire partie de l'URI, des paramètres de cordes de requête, du corps ou même des en-têtes. L'URI est utilisé pour identifier uniquement la ressource et le corps tient l'état de la ressource de demande. Une fois le traitement effectué par le serveur, une réponse appropriée est renvoyée au client via des en-têtes, un corps d'état ou de réponse.
Client-Server: il a une interface uniforme qui sépare les clients des serveurs. La séparation des préoccupations aide à améliorer la portabilité de l'interface utilisateur sur plusieurs plates-formes ainsi qu'à améliorer l'évolutivité des composants du serveur.
Interface uniforme: Pour obtenir l'uniformité tout au long de l'application, REST a défini quatre contraintes d'interface qui sont:
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
Cacheable: Afin de fournir une meilleure performance, les applications sont souvent rendues à cache. Cela se fait en étiquetant la réponse du serveur comme cacheable ou non caché implicitement ou explicitement. Si la réponse est définie comme cacheable, le cache client peut réutiliser les données de réponse pour les réponses équivalentes à l'avenir. Il aide également à prévenir la réutilisation des données périmées.
Système en couches: L'architecture du système en couches permet à une application d'être plus stable en limitant le comportement des composants. Cette architecture permet l'équilibrage de charge et fournit des caches partagées pour promouvoir l'évolutivité. L'architecture en couches aide également à améliorer la sécurité de l'application en tant que composants dans chaque couche ne peut pas interagir au-delà de la couche immédiate suivante dans laquelle ils se trouvent.
Code à la demande: le code à la demande est une contrainte facultative et est le moins utilisé. Il permet à un code ou à des applets de clients d'être téléchargés et étendus via l'interface à utiliser dans l'application. En substance, il simplifie les clients en créant une application intelligente qui ne s'appuie pas sur sa propre structure de code.
Maintenant que vous savez ce qu'est une API REST et ce que vous avez besoin pour vous soucier de fournir une application efficace, plongeons plus profondément et voyons le processus de construction de l'API REST en utilisant toutes les technologies tendance et FrameOWRKS.
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 RESTfuls sont apatrides. Une implémentation basée sur REST est simple par rapport au savon, mais les utilisateurs doivent comprendre le contexte et le contenu transmis, car il n'y a pas de ensemble de règles standard pour décrire l'interface de services Web Rest. Les services REST sont utiles pour les appareils de profil restreints, tels que le mobile, et sont faciles à intégrer aux sites Web existants.
Le savon nécessite moins de code de plomberie, ce qui signifie un code d'infrastructure de bas niveau qui connecte les modules de code principal ensemble que la conception des 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.
Ce sont quelques points à considérer lors du développement de l'API REST:
Des charges utiles extrêmement importantes de données de réponse ralentiront l'achèvement de la demande, d'autres appels de service et dans les performances de dégradation de l'affect. Comme vous le savez, maintenant que nous renvoyons toutes les commandes pour le client plutôt que leur commande actuelle, nous devrons faire face à une certaine dégraissement des performances.
Nous pouvons utiliser GZip Compression pour réduire notre taille de charge utile. Cela réduit la taille de téléchargement de notre réponse sur l'application Web (côté client), ainsi que d'augmenter la vitesse de téléchargement ou la création d'une entité (commandes). Nous pouvons utiliser Deflate compression sur une API Web. Ou, nous pouvons mettre à jour l'en-tête d'accept-codingRequest vers GZIP .
La mise en cache est l'une des méthodes les plus faciles pour améliorer les performances d'une API. Si nous avons des demandes qui redonnent fréquemment la même réponse, une version mise en cache de cette réponse permet d'éviter les appels de service / requêtes de base de données supplémentaires . Vous voudrez vous assurer que l'utilisation de la mise en cache invalidera périodiquement les données du cache, en particulier lorsque de nouvelles mises à jour de données se produisent.
Disons que notre client souhaite passer une commande pour une pièce automatique, et notre application appelle une API des pièces automobiles pour récupérer le prix de la pièce. Étant donné que la réponse (prix de la pièce) ne change qu'une fois par semaine (@ 1h00), nous pouvons mettre en cache la réponse pour le reste du temps jusque-là. Cela nous évite de passer un nouvel appel à chaque fois pour retourner le même prix de partie. Cas similaire, vous pouvez utiliser du cache pour éviter les appels ou les demandes supplémentaires.
Un réseau lent dégradera les performances de l'API, même conçue la plus robuste. Les réseaux peu fiables peuvent provoquer des temps d'arrêt, ce qui pourrait entraîner la violation des SLA, des conditions d'utilisation et des promesses que vous avez peut-être faites à vos clients. Il est important d'investir dans l'infrastructure de réseau appropriée, afin que nous puissions maintenir le niveau de performance souhaité. Cela peut être réalisé en tirant parti et en achetant suffisamment de ressources et d'infrastructures cloud (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . De plus, si vous avez une grande quantité de processus d'arrière-plan, exécutez ceux sur des threads séparés pour éviter de bloquer les demandes. Vous pouvez également utiliser des miroirs et des réseaux de livraison de contenu (CDN) tels que CloudFront pour des demandes plus rapidement dans différentes parties du globe.
Vous pouvez avoir une situation où votre API subit une attaque DDOS qui peut être malveillante et intentionnelle, soit ininitiionnelle lorsqu'un ingénieur appelle l'API à exécuter sur une boucle à partir d'une application locale. Vous pouvez éviter cela en mesurant les transactions et monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
Cette méthode de limitation des taux permet de réduire les demandes excessives qui ralentiraient l'API, aident à gérer les appels / exécutions accidentels et à surveiller et à identifier de manière proactive une activité malveillante possible.
C'est une idée fausse commune parmi les ingénieurs qui mettent et les opérations de correctif produisent le même résultat. Ils sont similaires dans la mise à jour des ressources, mais ils effectuent chacun les mises à jour différemment. Mettez les ressources de mise à jour des opérations en envoyant des mises à jour sur la ressource complète. Les opérations de correctif appliquent des mises à jour partielles uniquement aux ressources qui nécessitent une mise à jour. Les appels InPatch qui en résultent qui produisent des charges utiles plus petites et améliorent les performances à grande échelle.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
C'est peut-être l'un des conseils les plus importants que vous lirez ici. S'il y a une chose que vous devriez apprendre de ce dépôt, ce devrait être ceci! Aucune négociation sur celui-ci.
Le fait d'avoir des journaux, une surveillance et une alerte aident les ingénieurs à diagnostiquer et à résoudre les problèmes avant de devenir des problèmes . De nombreuses API (express / nœuds, Java, GO) ont prédéfini des critères de terminaison pour évaluer des choses comme:
`/health`
`/metrics`
Si vous n'avez pas de journalisation activé et qu'il y a un problème potentiel en cours, vous ne pourrez pas suivre l'origine ou où le problème se produit dans une demande particulière.
Si vous n'avez pas de surveillance activé, vous ne saurez pas dans une perspective analytique à quelle fréquence certains problèmes ou erreurs se produisent. Ce qui vous empêchera alors de penser à des solutions possibles.
Et… si vous n'avez pas activé d'alerte, vous ne saurez pas s'il y a un problème, jusqu'à ce qu'un client (ou pire, les clients) ne le signalent.
La pagination aide à créer des seaux de contenu à partir de plusieurs réponses . Ce type d'optimisation permet d'améliorer les réponses tout en préservant les données transférées / affichées à un client. Vous pouvez normaliser, segmenter et limiter les réponses qui aident à réduire la complexité des résultats et à améliorer l'expérience client globale en fournissant la réponse / résultats uniquement pour ce qu'un client a demandé.
Nous savons que les API sont incroyables et peuvent être extrêmement puissantes pour offrir à l'entreprise et aux clients une grande expérience, si elles sont correctement optimisées et améliorées pour les performances. Les exigences de l'entreprise et les attentes des clients évoluent toujours avec le temps. Et en tant qu'ingénieurs responsables, c'est à nous de décider comment construire nos API de manière performante, qui peut nous aider à atteindre et dépasser nos objectifs.
Ces conseils ne sont que la pointe de l'iceberg et s'appliquent à toutes les API en milieu général. Selon votre API et votre cas d'utilisation, avec quels services il interagit, à quelle fréquence il est appelé, d'où il est appelé, etc. Vous devrez peut-être mettre en œuvre ces conseils de différentes manières.
API REST avec Laravel - Passeport
API REST avec PHP - Oups
API REST avec Python - Flash
API REST avec Python - Django - Restframework
API REST avec Go - Mux
API REST avec Go - Gin
API REST avec Nodejs - Express - Basic
API REST avec Nodejs - Express- JWT - Sequellze - Advance
API REST très facile à créer en quelques minutes, vous pouvez choisir l'une des base de code ci-dessus en fonction de vos préférences de langue et de framework et de suivre les instructions pour créer l'API REST.
Codage heureux?
LinkedIn: https://www.linkedin.com/in/the-startup-cto/
Medium: https://apige.medium.com/
Twitter: https://twitter.com/htngapi
