Travailler avec des API peut être à la fois gratifiant et frustrant. D'une part, en interagissant avec d'autres applications, vous pouvez augmenter considérablement la portée de l'audience et l'effet « wow » de votre application. D'un autre côté, cela implique de lire des tonnes de documentation, d'étudier des stratégies d'authentification et d'analyser des messages d'erreur non informatifs (ou même manquants).

Tout d'abord, si vous ne comprenez toujours pas bien ce qu'est une API (Application Programming Interface), lisez l'explication de Skillcrush puis la première partie de cet article pour rattraper votre retard.

"API" est un concept incroyablement large : chaque fois que votre application "parle" avec une autre application, elle le fait via une sorte d'API. Les composants de votre propre application, comme les différentes parties de Rails, communiquent également entre eux via des API. Ce sont des sous-applications plus ou moins indépendantes qui fournissent les données dont chacune a besoin pour effectuer ses propres tâches spécifiques. Dans le monde des applications, tout est une API !

Lorsque vous créez des applications avec des fonctionnalités frontales plus dynamiques (à la fois des applications Javascript d'une seule page et des applications simples avec des appels AJAX individuels), elles communiqueront avec le backend Rails via votre propre API, qui n'est en réalité qu'une ou deux lignes supplémentaires de code. , indiquant à vos contrôleurs comment servir JSON ou XML au lieu de HTML.

Dans ce tutoriel, vous apprendrez à créer votre propre API. Dans les leçons suivantes, nous expliquerons comment interagir avec les API d'autres applications. Les leçons devraient constituer un bon tremplin pour en apprendre davantage sur ce sujet, mais il est peu probable qu’elles couvrent entièrement tous les cas. Une grande partie du travail avec les API consiste à savoir comment lire leur documentation et comprendre ce qu'elles attendent de vous.

Points à considérer

Passez en revue les questions et voyez si vous connaissez les réponses. Testez-vous à nouveau après avoir terminé la tâche.

• Comment Rails comprend le type de fichier que vous attendez en réponse lorsque vous envoyez une requête HTTP.
• Quel est le but de la méthode #respond_to ?
• Comment renvoyer un objet User tout en spécifiant les attributs que vous ne souhaitez pas inclure dans cet objet (c'est-à-dire que vous ne pouvez pas simplement renvoyer User.first) ?
• Nommez les 2 étapes en coulisses de la méthode #to_json.
• Comment demander à une action de contrôleur de n'afficher qu'un message d'erreur ?
• Comment créer votre propre message d'erreur ?
• Pourquoi ne pouvez-vous pas utiliser des méthodes d'authentification de contrôleur basées sur la session si vous souhaitez autoriser les connexions programmatiques à votre API ?
• Qu’est-ce que « l’architecture orientée services » ?

Bases de l'API

Votre application Rails est en fait déjà une API, même si vous ne la considérez peut-être pas comme une API. Le navigateur Web que vos utilisateurs lancent est également un programme, il envoie donc une requête API à votre application Rails lorsque l'utilisateur ouvre une nouvelle page. Nous avons tendance à penser de cette façon parce que le rendu des modèles HTML est une tâche si courante que nous intégrons simplement cette fonctionnalité dans nos programmes serveur en tant que type de réponse standard et considérons tout le reste comme quelque chose d'inhabituel.

Cependant, vous souhaitez souvent faire une demande qui ne nécessite pas de passer par tous les maux de tête liés à l'utilisation d'un navigateur. Vous ne vous souciez peut-être pas de la structure de la page (HTML), mais en retour, vous voulez des données propres. Disons que vous souhaitez obtenir une liste de tous les utilisateurs. Vous pouvez demander quelque chose comme http://yourapplication.com/users , qui déclenchera sûrement l'action #index et affichera une liste de tous les utilisateurs de l'application.

Mais pourquoi s’embêter avec toutes ces informations supplémentaires si tout ce que vous voulez est une liste d’utilisateurs ? L'option la plus simple serait d'envoyer une requête à la même URL et d'attendre une réponse JSON ou XML en retour. Si vous configurez correctement votre contrôleur Rails, vous obtiendrez un simple objet tableau JSON contenant tous les utilisateurs. Merveilleux!

Le même principe s'applique lorsque vous communiquez avec une API externe. Supposons que vous souhaitiez obtenir les tweets récents d'un utilisateur sur Twitter. Tout ce que vous avez à faire est d'indiquer à votre application Rails comment interagir avec l'API de Twitter (c'est-à-dire s'authentifier), envoyer la demande et traiter l'ensemble de "tweets" qui sera renvoyé.

Création d'une API

Vous souhaiterez peut-être faire de votre application Rails une pure API backend pour les pages Web frontales, ou vous souhaiterez peut-être simplement apprendre à envoyer du JSON lorsque le frontend le demande. Cette section n'expliquera pas comment créer des API RESTful à part entière avec des fonctions d'authentification. Il s'agit d'une introduction fluide au traitement de votre application comme une API.

Les bases

Si vous souhaitez que votre application Rails renvoie JSON au lieu de HTML, vous devrez demander à votre contrôleur de le faire. L'avantage est que la même action du contrôleur peut renvoyer différents types selon que votre utilisateur fait une requête régulière depuis le navigateur ou accède à l'API via la ligne de commande. Cela détermine le type de demande qui a été effectué en fonction de l'extension du fichier demandé, tel que example.xml ou example.json .

Vous pouvez vérifier ce que Rails pense du type de fichier que vous attendez en consultant le journal du serveur :

Démarrage de GET "/posts/new" pour 127.0.0.1 le 02/12/2013 à 15:21:08 -0800 Traitement par PostsController#new en HTML

La première ligne vous indique quelle URL a été demandée et la seconde vous indique où elle a été envoyée et comment Rails la traite. Si vous deviez utiliser l'extension .json, cela ressemblerait à ceci :

Démarrage de GET "/posts.json" pour 127.0.0.1 le 04/12/2013 à 12:02:01 -0800 Traitement par PostsController#index en tant que JSON

Si vous avez une application de test en cours d'exécution, essayez de demander des URL différentes. Si votre contrôleur ne peut pas les gérer, vous risquez d'obtenir une erreur, mais vous devriez toujours pouvoir voir ce que Rails comprend comme étant vos requêtes.

Rendu JSON ou XML

Une fois que vous décidez que vous souhaitez répondre aux requêtes en utilisant JSON ou XML, vous devrez demander à votre contrôleur de restituer JSON ou XML au lieu de HTML. Une façon de procéder consiste à utiliser la méthode #respond_to :

Classe UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

Dans ce cas, #respond_to transmet un objet de format au bloc, auquel vous pouvez attacher un appel de rendu correspondant. Si vous ne faites rien, le code HTML sera rendu en utilisant le modèle Rails standard (dans cet exemple app/views/index.html.erb).

La fonction #render est suffisamment intelligente pour comprendre comment restituer un large éventail de formats. Lorsque vous lui transmettez la key:json , il appellera #to_json sur la valeur, dans cet exemple @users . Cela convertira vos objets Ruby en chaînes JSON qui seront transmises à l'application demandeuse.

De cette façon, vous obtenez votre API. Bien sûr, créer une API peut être un peu plus complexe si vous souhaitez faire des choses sophistiquées, mais tout s'en tient à l'essentiel.

Spécification des attributs renvoyés

Supposons que vous souhaitiez vous assurer de ne pas renvoyer l'adresse e-mail de l'utilisateur avec l'objet User. Dans ce cas, vous souhaiterez changer les attributs qui seront renvoyés, en modifiant ce que fait la méthode #to_json.

Auparavant, vous auriez simplement remplacé la méthode #to_json par votre version, mais maintenant vous n'en aurez plus besoin - en fait, vous remplacerez plutôt la méthode #as_json. La méthode #as_json est utilisée dans la méthode #to_json, donc sa modification change implicitement le résultat de #to_json , mais de manière assez spécifique.

#to_json fait 2 choses : il exécute #as_json et obtient un hachage des attributs qui seront rendus en JSON. Il est ensuite rendu en JSON à l'aide de ActiveSupport::json.encode . Ainsi, en modifiant #as_json, vous êtes plus précis sur la partie de la méthode #to_json que vous souhaitez réellement modifier.

Dans notre cas, nous faisons cela en modifiant #as_json dans notre modèle pour renvoyer uniquement les attributs dont nous avons besoin :

# app/models/user.rb classe Utilisateur< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # NE PAS inclure le champ email end # Option 2 : Utiliser la méthode standard #as_json def as_json(options=()) super(only: [:name]) end end

Ensuite, notre contrôleur n'aura plus qu'à restituer le JSON comme d'habitude (l'exemple ci-dessous renverra toujours JSON, qu'une requête HTML ait été envoyée ou non) :

# classe app/controllers/users_controller.rb UsersController< ApplicationController def index render json: User.all end end

Notez que vous n'avez pas besoin d'appeler #to_json vous-même lorsque vous utilisez #render - il le fera pour vous.

Parfois, Heroku peut nécessiter des étapes supplémentaires pour afficher correctement vos pages d'erreur. Jetez un oeil. Vous devrez peut-être d'abord supprimer les pages statiques du répertoire app/public.

Assurer la sécurité depuis l’extérieur

Supposons que vous souhaitiez autoriser l'accès à l'API uniquement si l'utilisateur est connecté. Votre authentification existante dans le contrôleur fait déjà ce travail - assurez-vous simplement d'avoir le bon ensemble #before_action (par exemple before_action:require_login). Vous aurez peut-être besoin d'une fonctionnalité permettant aux utilisateurs connectés et non connectés de voir la page, mais chacun devrait voir des données différentes. Vous ne voulez pas que des utilisateurs non authentifiés puissent effectuer des appels API pour obtenir des données sensibles. De même, vous ne souhaitez pas autoriser des utilisateurs non autorisés à visiter certaines pages HTML.

Si vous souhaitez traiter des requêtes provenant d'une application qui n'est pas un navigateur (par exemple, depuis la ligne de commande), vous ne pouvez pas vous fier aux « cookies » du navigateur pour l'authentification. C'est pourquoi la plupart des API utilisent des jetons natifs dans le cadre du processus d'authentification. Nous parlerons un peu plus des jetons dans la prochaine leçon.

Prochaines étapes

Vous disposez désormais des compétences nécessaires pour utiliser votre application Rails pour afficher non seulement du HTML, mais également tout autre format. Si vous souhaitez aller plus loin et permettre à d'autres développeurs de créer des éléments en utilisant votre plateforme (par exemple, afin qu'ils puissent effectuer des requêtes programmatiques au lieu de s'authentifier en tant qu'utilisateur), vous devrez rendre votre système API beaucoup plus robuste. Nous ne couvrirons pas tout ici, mais vérifiez ce qui suit :

• L'article Building Awesome Rails API décrit bon nombre des meilleures approches pour passer d'une application de jouet aux normes d'API industrielles.

Architecture orientée services

Il est temps d'introduire une approche architecturale appelée Architecture Orientée Services (SOA). L'idée de base est que votre application sera composée de nombreux services, tels qu'un système de paiement, l'enregistrement des utilisateurs, un module de recommandation, etc. Au lieu de tout construire dans une seule application principale, vous divisez les sous-systèmes en éléments complètement indépendants qui communiquent entre eux à l'aide d'API internes.

C’est une bonne chose pour de nombreuses raisons. Étant donné que chaque élément de votre application ne se soucie pas du fonctionnement des autres éléments et sait uniquement comment demander des données via son API, vous pouvez apporter des modifications significatives au code du service et le reste de l'application fonctionnera comme avant. Vous pouvez complètement remplacer un service par un autre, et tant qu’il communique en utilisant les mêmes méthodes API, tout se passera très bien. Vous pouvez utiliser des API externes dans le cadre de votre application (par exemple des systèmes de paiement) au lieu d'écrire les vôtres. Vous pouvez créer une application PHP qui communique avec une application Python qui communique avec une application Rails, et tout fonctionnera car elles communiquent entre elles à l'aide d'une API.

C'est généralement une bonne idée d'essayer de rendre chaque partie de votre application aussi indépendante que possible. Le concept SOA vous oblige à réfléchir aux méthodes que vous souhaitez exposer à d'autres parties de votre application, et cela améliorera également votre code. De plus, en supposant que chaque composant majeur de votre application est indépendant, vous pourrez également isoler les problèmes beaucoup plus facilement et gérer les erreurs de manière plus significative.

Utiliser une architecture orientée services pour une application entière revient à diviser un script Ruby géant et complexe en classes et méthodes soignées, mais à plus grande échelle.

L'un des cas les plus célèbres de transition vers une architecture orientée services est celui d'Amazon.com. Un jour de 2002, Jeff Bezos a déclaré sans ambages que tous les groupes de travail devaient passer à SOA ou être licenciés. Célèbre article de blog Un employé de Google, destiné à des fins internes mais rendu public accidentellement, a parlé de la puissance d'Amazon utilisant SOA. C'est une excellente lecture, alors assurez-vous de la consulter, mais les principaux points de la lettre de Bezos sont résumés dans les citations suivantes du message :

1) Toutes les équipes fournissent désormais leurs données et fonctionnalités via des interfaces de service.

2) Les équipes doivent communiquer entre elles via ces interfaces.

3) Les autres formes de communication interprocessus sont interdites : pas de liens directs, pas de lecture directe des données d'une autre commande, pas de modèles de mémoire partagée, pas de portes dérobées, etc. Le seul moyen d'interaction autorisé consiste à accéder à l'interface de service via le réseau.

4) Peu importe la technologie utilisée. HTTP, Corba, Pubsub, protocoles propriétaires - aucune différence. Bezos s'en fiche.

5) Toutes les interfaces de service, sans exception, doivent être initialement conçues avec la possibilité d'être contrôlées de l'extérieur. Autrement dit, l’équipe doit planifier et concevoir pour pouvoir fournir l’interface aux développeurs extérieurs à l’entreprise. Aucune exception.

6) Quiconque ignore ces exigences sera licencié.

La SOA est une affaire sérieuse. Bien sûr, de nombreux problèmes surviennent lors de son utilisation – consultez cet article sur les « leçons apprises » d’Amazon – mais il présente une quantité incroyable d’avantages.

Vous ne vous soucierez probablement pas trop de la SOA lorsque vous créerez des applications de jouets pour vous-même, mais c'est certainement un problème qui surviendra lorsque vous commencerez à travailler pour une entreprise informatique, donc se familiariser avec elle est une bonne pratique.

Votre objectif

1. Lisez la section 7 du Guide des contrôleurs Rails pour en savoir plus sur le rendu JSON et XML.
2. Ils ne sont pas obligatoires (car ils vont un peu plus loin que ce à quoi nous sommes actuellement préparés), mais si vous êtes intéressé, jetez un œil aux Railscasts dans la section Ressources supplémentaires au bas de la leçon pour en savoir plus sur le avantages de l'API.

Conclusion

Nous travaillerons plus étroitement avec votre application en tant qu'API pendant le cours Javascript. Dans ce cours, vous créerez plusieurs applications full-stack qui utilisent les appels AJAX pour une meilleure expérience utilisateur, ce qui implique essentiellement le rendu de données XML ou JSON au lieu d'une page HTML complète. Vous créerez ensuite plusieurs applications Javascript d'une seule page qui s'appuient sur l'API fournie par votre application Rails pour récupérer toutes les données nécessaires de la base de données, mais qui autrement s'exécuteront côté client (dans le navigateur).

La meilleure façon de comprendre une API est de la créer et d’interagir avec elle, c’est ce sur quoi nous nous concentrerons dans nos projets.

API - qu'est-ce que c'est ? Décryptage, définition, traduction

API est une abréviation anglaise, qui représente UN application P. programmation je ninterface - « Interface de programmation d'applications ». En règle générale, une API est un ensemble de fonctions pratiques qui vous permettent d'accéder à un service et d'en demander des données. En anglais, cette abréviation se prononce « hey-pee-ay », mais les programmeurs russophones ne se compliquent pas inutilement la vie et ne disent pas « ápi ».

Un exemple classique d'API est Yandex.maps : tout programmeur ou webmaster plus ou moins expérimenté peut placer une carte Yandex de n'importe quelle ville ou village avec les paramètres dont il a besoin sur son site Web, en utilisant des fonctions API pratiques, qui, soit dit en passant, sont fourni par Yandex entièrement gratuitement et inclut la quasi-totalité des paramètres cartographiques disponibles pour les utilisateurs du site Web Yandex.Maps.

Avez-vous découvert d'où vient le mot ? API, son explication en mots simples, sa traduction, son origine et sa signification.

Afin de faciliter le travail de leurs collègues et de fournir à tous les programmes Windows une interface universelle, les programmeurs Microsoft ont créé une API - "Application Programming Interface".

Il s'agit d'un ensemble de fonctions et de procédures qui peuvent être le plus souvent utilisées par les programmes : afficher une arborescence de répertoires, rechercher des fichiers, afficher une fenêtre standard avec des boutons de fermeture, de réduction et d'agrandissement, et bien d'autres. En conséquence, un développeur créant un programme pour Windows n'a pas besoin de réfléchir et de développer des sous-programmes spéciaux pour afficher la fenêtre du programme, la fenêtre de sélection d'un dossier et d'autres opérations élémentaires similaires - il lui suffit d'appeler kernel32.dll ou user32. dll des bibliothèques contenant les fonctions et procédures API, la fonction dont il a besoin, et elle fera tout elle-même pour lui. Il existe de nombreuses fonctions et procédures de ce type - environ 600.

Dans le système d'exploitation MS-DOS, l'API n'existait pas - celui qui entreprenait d'écrire un programme pour ce système d'exploitation était obligé de réfléchir et de mettre en œuvre des méthodes d'affichage d'images à l'écran, de recevoir des données de l'utilisateur, du début à la fin, parcourir le système de fichiers, dessiner des graphiques, si une telle possibilité était nécessaire 2. Cela a fait du processus de développement de programmes avec une interface conviviale un processus très laborieux ; souvent, le temps et les efforts consacrés à la création d'une interface graphique acceptable pour le programme dépassaient les coûts de mise en œuvre du propre algorithme du programme, pour lequel il a été créé. . Ce n'est pas pour rien que les applications dites « consoles » étaient très courantes, c'est-à-dire des programmes qui fonctionnaient uniquement à partir de la ligne de commande, sans interface - les données étaient saisies sur la même ligne de commande ou créées à partir d'un fichier qui y était spécifié, et les résultats ont été affichés en mode texte simple.

Avec l'avènement du système d'exploitation Windows, le travail acharné des programmeurs pour développer l'apparence du programme et des méthodes pratiques de saisie et de sortie d'informations a été grandement facilité - les fonctions API étaient déjà utilisées dans Windows 3.0. Maintenant, le programmeur, si, par exemple, il voulait créer une fenêtre de saisie de texte ou une barre de défilement, il lui suffisait d'écrire un appel à la fonction permettant d'afficher une telle fenêtre avec les paramètres dont il avait besoin, comme n'importe quelle autre fonction du programme. langage dans lequel il a écrit son programme, et de ne pas introduire d'énormes quantités de code pour créer un programme qui redessine une telle fenêtre ou barre (tout en étant conscient que lors du développement du prochain programme utilisant également de tels objets, il devra développer refaire ce code ou essayer d'utiliser partiellement l'ancien, en l'adaptant aux besoins de ce nouveau programme). Par conséquent, l'émergence de l'API a constitué une percée révolutionnaire dans la technologie de programmation, vous permettant de créer beaucoup plus rapidement les programmes nécessaires avec une interface familière et pratique, sans vous soucier de détails de routine tels que la programmation d'objets d'interface standard pour l'entrée et la sortie d'informations.

Dans le langage Visual Basic pour Applications (VBA), de nombreuses fonctions et procédures API sont appelées elles-mêmes lorsque le programme est exécuté par l'interpréteur, il n'est donc absolument pas nécessaire de les utiliser pour afficher des fenêtres de saisie et de sortie de texte, dessiner des formes géométriques sur le écran et autres actions simples - VBA les appelle selon les besoins et le programme qui s'y trouve n'a besoin que d'utiliser les fonctions appropriées de ce langage. Cependant, certaines actions sont parfois nécessaires pour lesquelles soit il n'y a pas d'analogues dans les fonctions VBA intégrées, soit elles fonctionnent de manière irrationnelle ou trop lente. Par exemple, une fenêtre de sélection de dossier avec une image d'une arborescence de répertoires (Fig. 5.1) ou un programme de recherche de fichiers (analogue dans les fonctions VBA - l'objet "Application.FileSearch" - fonctionne trop lentement avec un grand nombre de fichiers). Dans de tels cas, VBA offre la possibilité d'appeler des fonctions API.

Malheureusement, l'utilisation des fonctions API dans VBA n'est pas documentée dans l'aide, donc pour apprendre à les utiliser, vous devez soit rechercher des livres ou des sources en ligne sur la programmation bureautique, soit analyser le code des programmes contenant des appels aux fonctions API.

Dans la grande majorité des cas, lors de la programmation pour Office, vous pouvez vous passer de l'API, mais parfois le simple appel d'une fonction API peut obtenir le résultat souhaité. Disons que vous devez vous assurer que différentes macros sont appelées lorsque vous cliquez simplement sur un bouton d'une barre d'outils Word avec la souris et lorsque vous appuyez simultanément sur ce bouton et sur la touche Maj ou Contrôle. Voici un extrait de code faisant ceci :

Déclarer la fonction GetAsyncKeyState Lib "user32.dll" (ByVal kState As Long) sous forme d'entier

GetAsyncKeyState (vbKeyShift ou vbKeyControl)

Si GetAsyncKeyState(vbKeyShift) Alors

Appeler la macro1 : Quitter le sous-marin

ElseIf GetAsyncKeyState(vbKeyControl) Alors

Appeler la macro2 : Quitter le sous-marin

La première ligne revient à « réserver » une fonction API pour une utilisation dans un programme VBA. On voit que la fonction GetAsyncKeyState est appelée depuis la bibliothèque (un fichier contenant des programmes destinés uniquement à être utilisés par d'autres programmes) user32.dll, et le numéro de clé est passé à cette fonction, et elle renvoie un entier (à savoir 0, si la touche avec le numéro correspondant n'est pas enfoncée, et -32767 ou 1 si enfoncée). Toute fonction ou procédure appelée à partir de bibliothèques non VBA doit être ainsi réservée à l'aide de la commande Declare.

L'expression vbKeyShift dans la commande remplace le code de la touche Shift (sa valeur est 16) et vbKeyControl, comme il est facile à comprendre, remplace le code de la touche Control. La structure des instructions "If...Then" semble claire 3, mais sinon, consultez l'aide de VBA. La commande Appeler avant le nom de la macro, comme vous vous en souvenez, signifie la lancer.

Il existe des sites russes sur Internet dédiés à l'API 4. Visitez-les pour en savoir plus sur cet ensemble de fonctionnalités.

, fonctions, structures ou constantes) avec lesquels un programme informatique peut interagir avec un autre programme. Généralement inclus dans la description d'un protocole Internet (par exemple, RFC), d'un cadre logiciel (framework) ou d'une norme d'appel de fonction du système d'exploitation. Souvent implémenté par une bibliothèque logicielle distincte ou un service de système d'exploitation. Utilisé par les programmeurs lors de l'écriture de toutes sortes d'applications.

L'API comme moyen d'intégration d'applications

L'API définit la fonctionnalité fournie par le programme (module, bibliothèque), tandis que l'API vous permet de faire abstraction de la manière exacte dont cette fonctionnalité est implémentée.

Si un programme (module, bibliothèque) est considéré comme une boîte noire, alors l'API est un ensemble de « poignées » qui sont à la disposition de l'utilisateur de cette boîte et qu'il peut faire tournoyer et tirer.

Les composants logiciels interagissent les uns avec les autres via des API. Dans ce cas, les composants forment généralement une hiérarchie - les composants de haut niveau utilisent l'API des composants de bas niveau et, à leur tour, utilisent l'API de composants de niveau encore plus bas.

Les protocoles de transfert de données sur Internet reposent sur ce principe. La pile de protocoles standard (modèle de réseau OSI) contient 7 couches (de la couche de transfert de bits physique à la couche de protocole d'application comme les protocoles HTTP et IMAP). Chaque couche utilise les fonctionnalités de la couche de transfert de données précédente (« inférieure ») et, à son tour, fournit les fonctionnalités nécessaires au niveau suivant (« supérieur »).

Il est important de noter que le concept de protocole est proche du concept d'API. Les deux sont des abstractions de fonctionnalités, seulement dans le premier cas, nous parlons de transfert de données et dans le second, nous parlons d'interaction d'applications.

L'API de la bibliothèque de fonctions et de classes comprend une description signature Et sémantique des fonctions.

Signature de fonction

Parfois, ils distinguent signature d'appel Et signature de mise en œuvre fonctions. Une signature d'appel est généralement compilée à partir de la structure syntaxique d'un appel de fonction, en tenant compte de la signature de la portée de la fonction donnée, du nom de la fonction, de la séquence des types réels d'arguments dans l'appel et du type de l'appel. résultat. La signature d'implémentation comprend généralement certains éléments de la structure syntaxique de la déclaration de fonction : un spécificateur de portée de fonction, son nom et une séquence de types d'arguments formels.

Par exemple, dans le langage de programmation C++, une fonction simple est identifiée de manière unique par le compilateur par son nom et la séquence de types de ses arguments, qui constitue la signature de la fonction dans ce langage. Si une fonction est une méthode d'une certaine classe, le nom de la classe sera également inclus dans la signature.

Dans l'industrie du logiciel, les API standard communes pour les fonctionnalités standard jouent un rôle important car elles garantissent que tous les programmes utilisant une API commune fonctionneront aussi bien, ou du moins d'une manière généralement familière. Dans le cas des API GUI, cela signifie que les programmes auront une interface utilisateur similaire, ce qui facilite l'apprentissage de nouveaux produits logiciels.

D’un autre côté, les différences entre les API des différents systèmes d’exploitation rendent très difficile le portage d’applications entre plates-formes. Il existe différentes méthodes pour contourner cette complexité : écrire des API "intermédiaires" (wxWidgets, GTK, etc. API GUI), écrire des bibliothèques qui mappent les appels système d'un système d'exploitation aux appels système d'un autre système d'exploitation (des environnements d'exécution tels que Wine, cygwin, etc. .), introduction de standards de codage dans les langages de programmation (par exemple, la bibliothèque standard du langage C), écriture de langages interprétés implémentés sur différentes plateformes (python, perl, php, tcl, Java, etc.).

Il faut également noter que le programmeur dispose souvent de plusieurs API différentes pour arriver au même résultat. De plus, chaque API est généralement implémentée à l’aide de composants logiciels API d’un niveau d’abstraction inférieur.

Par exemple : pour voir la ligne « Hello, world ! » dans le navigateur. ", il vous suffit de créer un document HTML avec un titre minimal et un corps simple contenant cette ligne. Lorsque le navigateur ouvre ce document, le programme de navigation transmettra le nom du fichier (ou un descripteur de fichier déjà ouvert) à la bibliothèque qui traite les documents HTML, qui, à son tour, à l'aide de l'API du système d'exploitation, lira ce fichier et comprendra sa structure. , puis appelez séquentiellement via la bibliothèque API des opérations de primitives graphiques standard telles que « effacer la fenêtre », « écrire « Bonjour tout le monde dans la police sélectionnée ». Lors de l'exécution de ces opérations, la bibliothèque de primitives graphiques contactera la bibliothèque d'interface de fenêtre avec les requêtes appropriées, et cette bibliothèque appellera l'API du système d'exploitation pour écrire des données dans le tampon de la carte vidéo.

De plus, à presque chaque niveau, il existe en réalité plusieurs API alternatives possibles. Par exemple : nous pourrions écrire le document source non pas en HTML, mais en LaTeX, et nous pourrions utiliser n'importe quel navigateur pour l'afficher. De plus, différents navigateurs utilisent différentes bibliothèques HTML et, de plus, tout cela peut être compilé à l'aide de différentes bibliothèques primitives et sur différents systèmes d'exploitation.

Les principaux défis des systèmes API multi-niveaux existants sont donc :

• Difficulté à porter le code du programme d'un système API à un autre (par exemple, lors d'un changement d'OS) ;
• Perte de fonctionnalité lors du passage d'un niveau inférieur à un niveau supérieur. En gros, chaque « couche » API est créée pour faciliter l’exécution d’un ensemble standard d’opérations. Mais en même temps, il devient très difficile, voire fondamentalement impossible, d'effectuer certaines autres opérations fournies par un niveau d'API inférieur.

API les plus connues

Systèmes d'exploitation

Par définition de Wikipédia, une API est un ensemble de classes, procédures, fonctions, structures et constantes prêtes à l'emploi fournies par une application (bibliothèque, service) pour être utilisées dans des produits logiciels externes. Utilisé par les programmeurs pour écrire toutes sortes d'applications.

Mais comme une grande partie de Wikipédia n’est pas compréhensible pour beaucoup de gens, je vais essayer d’expliquer en termes simples ce qu’est une API, à quoi elle sert habituellement et comment elle est utilisée.

Les API sont complètement différentes, mais à titre d'exemple, j'ai choisi une situation où nous avons un réseau de magasins et une seule base de données commune. Imaginez que vous possédez un programme d'affiliation. Le programme d'affiliation fonctionne sur le principe suivant : une personne s'inscrit au programme d'affiliation et reçoit un moteur de boutique. Il pourra ensuite installer cette boutique sur son hébergement et commencer à travailler. Mais toutes les données de cette boutique sont extraites de notre base de données, c'est-à-dire que nous devons donner à chaque partenaire l'accès à notre précieuse base de données. Pouvez-vous imaginer à quel point c'est dangereux ? Après tout, nous devons ouvrir l'accès à la base de données de l'extérieur afin que tous les magasins partenaires puissent l'utiliser. Que se passe-t-il si vos données d'accès tombent entre les mains de criminels ?

C'est là que l'API nous aidera. Au lieu de donner accès à la base de données, nous créerons simplement une API via laquelle les magasins partenaires recevront des informations. De cette façon, seul notre script API fonctionnera avec la base de données et les magasins fonctionneront avec ce script.

Comment cela marche-t-il?
Par exemple, un magasin envoie une requête à notre API
http://ourapi.com/get_books?limit=20
et notre API comprend qu'elle doit lui donner une liste de livres composée de 20 exemplaires, car nous avons passé le paramètre limite égal à 20. Notre script (API) fait une requête à la base de données, reçoit une liste de livres et les renvoie à le magasin (en fait, il affiche simplement ) dans un format spécifique. Le format dans lequel l'API renvoie les informations peut être absolument n'importe quoi, l'essentiel est que nos magasins le comprennent. Il peut s'agir de JSON, d'un tableau sérialisé ou de XML. Ce n’est plus important, l’essentiel est que vous compreniez le principe.

Vous définissez vous-même l'ensemble des commandes que l'API comprend. Par exemple, dans notre cas, il pourrait s'agir de commandes telles que obtenir une liste de livres, obtenir une liste de catégories, obtenir des livres populaires, obtenir de nouveaux livres, etc. De cette façon, même si un attaquant a la possibilité d'accéder à notre API, tout ce qu'il peut faire est d'obtenir une liste de livres, et cela ne représente aucune menace pour notre base de données.

J'espère avoir pu expliquer ce qu'est une API avec un exemple simple. Si vous avez des questions, posez-les dans les commentaires ou sur le forum et nous nous ferons un plaisir de vous aider à les résoudre.