Comment fonctionnent les API Web? [fermé]

J'ai entendu parler de nombreuses API Web comme celle de Facebook, Twitter, etc., qui aident les tiers à accéder aux données et à les manipuler. Je voudrais savoir comment fonctionne une API Web. Quelles sont les bases d'une API Web?

Si je veux créer une API pour mon site, afin que les gens puissent y accéder ou le mettre à jour, de quoi ai-je besoin pour commencer?

Au plus simple, vous créez un ensemble de demandes GET / POST que n'importe qui peut appeler et publier les informations sur les URL, les paramètres et les effets. OBTENEZ des demandes de tâches en lecture seule et des demandes POST pour tout ce qui changera les données sur le serveur.

Ajoutez un système d'authentification si nécessaire et vous avez vous-même une simple API Web.

Une API Web n'est qu'une interface pour permettre l'accès à votre système (comme un site) via des méthodes de requête HTTP standard . Les données elles-mêmes sont généralement enveloppées dans un format standard (tel que JSON ou XML ) pour en faciliter la gestion.

Voici un exemple d' API Web pour 'TextWise'

Je développe actuellement une API pour la plate-forme de virtualisation de mon entreprise. Vous pouvez les aborder de différentes manières, mais mon préféré (et la voie la plus rapide pour faire fonctionner quelque chose que les gens peuvent comprendre) consiste à utiliser de simples requêtes HTTP GET et à renvoyer une réponse JSON.

Mon URL ressemble à ceci:

domain.com/method/call/subcall?key=key&data=something

Je décompose ensuite les variables HTTP GET et fais ce que l'appelant veut en faire. L'une des principales raisons pour lesquelles je me suis inscrit en tant qu'utilisateur bêta au développement de l'API Stack Exchange était que je savais que ce serait une expérience d'apprentissage formidable, et en effet, elle l'était .

Habituellement, je retourne deux tableaux codés JSON, l'un étant result, qui indique simplement si l'appel a réussi et donne un code d'erreur / une chaîne d'erreur dans le cas contraire. L'autre est généralement simplement appelé data, et le contenu de celui-ci est décrit dans la documentation de cet appel particulier. De plus, les API basées sur GET sont beaucoup plus faciles à tester et à déboguer.

Il existe de nombreux autres formats, comme SOAP / XMLRPC, je trouve juste que le choix de JSON me donne une simplicité et une liberté de choix incroyables.

Par exemple, si j'ai besoin d'envoyer beaucoup de champs et que je ne veux pas traiter avec une tonne de variables GET, je peux simplement le faire (exemple en PHP)

$to_send = base64_encode(json_encode($some_array));

Cela est facilement décodé de l'autre côté, ce qui me donne des dizaines de variables avec lesquelles travailler, tout en n'acceptant que 2 à 3 variables GET via l'API.

J'essaie simplement de garder mes méthodes et mes appels courts et succincts, et de les concevoir de manière à ce que chaque appel renvoie une réponse uniforme `` travaillé ou échoué '', suivie des données demandées.

C'est en fait une question très large. Dans le sens le plus élémentaire, une API Web fonctionne lorsqu'un client (comme un navigateur Web) fait une requête HTTP quelconque à un serveur Web. Le serveur examine cette demande pour comprendre ce que veut l'utilisateur, puis renvoie les données dans un certain format (comme une page) que le client examine ensuite pour obtenir ce qu'il veut. Ce sont à peu près les seules choses que les API Web ont en commun; Je me rends compte que cela ne répond pas vraiment à votre question, mais je voulais expliquer pourquoi la question est si large.

Il existe toutes sortes de façons dont un client peut formater sa demande, ou qu'un serveur puisse formater sa réponse, et donc pour que cela ait du sens, le client et le serveur doivent se mettre d'accord sur certaines règles de base. De manière générale, il existe de nos jours deux styles très généraux qui s'utilisent pour ce genre de chose.

Appel de procédure à distance (RPC)

Dans une API de style RPC, il n'y a généralement qu'une seule URL pour l'ensemble de l'API. Vous l'appelez en POSTANT un document quelconque qui contient des informations sur ce que vous voulez faire, et le serveur renvoie le document qui contient ce que vous voulez. En termes informatiques généraux, le document de demande a généralement un nom de fonction et quelques arguments.

Certaines normes pour ce style d'API incluent XML-RPC et SOAP. Ces normes tentent de créer un format qui peut être utilisé pour décrire les appels de fonction que vous effectuez, ou même pour décrire l'ensemble de l'API.

Transfert d'état représentatif (REST)

Dans une API de style REST, vous n'avez pas tant d'URL pour l'API qu'un espace de noms : un serveur ou un dossier à l'intérieur d'un serveur, où résident de nombreux objets différents, et chaque URL de cet espace de noms fait partie de l'API. Au lieu de dire au serveur que vous souhaitez utiliser l'API, l'URL indique au serveur ce que vous voulez utiliser l'API sur . Vous utilisez ensuite la méthode HTTP, et éventuellement le corps de la demande, pour expliquer ce que vous voulez faire pour cet objet: GET (récupérer quelque chose qui est déjà là), POST (créer quelque chose de nouveau), PUT (remplacer quelque chose qui est déjà là), ou SUPPRIMER (se débarrasser de quelque chose qui est déjà là). Il existe quelques autres verbes que vous pouvez utiliser, mais ceux-ci sont de loin les plus courants.

Jusqu'à présent, je n'ai pas mentionné de formats standard pour REST. En théorie, vous pouvez utiliser n'importe quel format. HTTP prévoit déjà de dire ce que vous voulez faire et ce que vous voulez faire, de sorte que le format du corps de la demande pourrait être à peu près n'importe quoi: une représentation de l'objet que vous souhaitez créer ou remplacer. Mais dans la pratique, les auteurs REST ont tendance à s'entendre sur un format de toute façon, car il serait difficile de donner un sens à tous les formats possibles.