Les interfaces de programmation applicative (API)

On désigne par interface de programmation applicative API un ensemble normalisé de code permettant de fournir des services à d’autres logiciels dans d’autres runtime d’exécution éventuellement. Elles sont très utilisées par les applications modernes. On utilise des fonctionnalités fournies par un tiers.

Les grands acteurs du web proposent leur API notamment Google, Amazon, Facebook, IBM. On peut citer Google Maps Android API, Social Plugins de Facebook par exemple.
Ces interactions entre application permettent une monétisation des échanges de manière automatique selon la fréquence et la charge d’utilisation. Les fournisseurs proposent une documentation pour utiliser leur application mais très rarement une documentation de la logique applicative, ceci pour éviter toute falsification.

Ces API proposent principalement un échange d’information dans un format standard, le JSON sur le protocole HTTP.

 

 

Open API

Les API ouvertes révolutionnent l’ensemble de l’écosystème applicatif. Elles donnent accès à une partie des données aux développeurs tiers (qui ne font pas partie de l’organisation). Ces développeurs peuvent ainsi tirer profit de ces services pour améliorer leur propre application moyennant rétribution au fournisseur. Il n’y a pas de lien commercial direct, la souscription de service se fait via l’utilisation des applications à ces services et sous condition d’acceptation de certaines règles propres à chaque entreprise fournissant le service. Les entreprises n’ont toutefois pas d’idée préconçue sur l’usage qui en sera fait.

La notion de « open » ne sous-entend pas que tout est ouvert. Seuls les éléments publics (et publiés) sont exposés. Les données critiques ne peuvent faire l’objet d’API ouvertes comme les banques ou le domaine médical sauf pour des relations B2B authentifiées. Un second frein est la performance pour des chaines de décision en temps réel comme l’aviation ou l’automobile.

Un contrôle reste nécessaire sur les accès, la sécurité globale du système d’information et la protection de l’utilisateur final. La protection est une affaire d’interprétation, il se peut donc que des API fournissent des services potentiellement néfastes pour certains utilisateurs.

Les Services Web

Un service web est un programme de la famille des technologies web permettant la communication et l’échange de données entre applications et systèmes hétérogènes dans des environnements distribués.

Il existe plusieurs technologies derrière le terme « services web » :

  • Les services web de type REpresentational State Transfer (REST) exposent entièrement ces fonctionnalités comme un ensemble de ressources (URI) identifiables et accessibles par la syntaxe et la sémantique du protocole http. Les Services Web de type REST sont donc basés sur l’architecture du web et ses standards de base : http et URI ;
  • Les services web WS-* exposent ces mêmes fonctionnalités sous la forme de services exécutables à distance. Leurs spécifications reposent sur les standards SOAP et WSDL pour transformer les problématiques d’intégration héritées du monde Middleware en objectif d’interopérabilité.

Un service web est une page capable de recevoir et d’envoyer des informations via un « protocole » spécifique (SOAP ou REST).

Les contraintes de REST

  1. Le client et le serveur possèdent chacun des rôles différents et l’interface utilisateur ne peut stocker les données.
  2. Chaque requête du client vers le serveur doit contenir toute l’information nécessaire pour son exécution.
  3. Le serveur informe le client de la date de création de la réponse et du temps de conservation.
  4. Une interface uniforme ; une identification des ressources unique, une définition des types des ressources utilisées, un message qui indique le format, son encodage. Chaque accès aux états suivants de l’application est décrit dans le message courant.
  5. Les informations sont hiérarchisées et renvoyées selon ce découpage.
  6. Facultatif : exécuter des scripts coté client obtenus par le serveur.

Pour implémenter cet ensemble de contraintes, on peut définir plus précisément des règles pour l’élaboration d’une API REST. Voici l’exemple de Nicolas Hachet, architecte développeur PHP :

  • Règle n°1 : l’URI comme identifiant des ressources ;
  • Règle n°2 : les verbes HTTP comme identifiant des opérations ;
  • Règle n°3 : les réponses HTTP comme représentation des ressources ;
  • Règle n°4 : les liens comme relation entre ressources.
  • Règle n°5 : un paramètre comme jeton d’authentification

Règle n°1 : l’URI comme identifiant des ressources

Liste des livres
NOK : http://frebourg.ninja/book
OK : http://frebourg.ninja/books

Filtre et tri sur les livres
NOK : http://frebourg.ninja/books/filtre/policier/tri/asc
OK : http://frebourg.ninja/books?fitlre=policier&tri=asc

Affichage d’un livre
NOK : http://frebourg.ninja/book/display/87
OK : http://frebourg.ninja/books/87

Tous les commentaires sur un livre
NOK : http://frebourg.ninja/books/comments/87
OK : http://frebourg.ninja/books/87/comments

Affichage d’un commentaire sur un livre
NOK : http://frebourg.ninja/books/comments/87/1568
OK : http://frebourg.ninja/books/87/comments/1568

Règle n°2 : les verbes HTTP comme identifiant des opérations

On peut utiliser les méthodes HTTP pour ses opérations

  • Créer => POST
  • Afficher => GET
  • Mettre à jour => PUT
  • Supprimer => DELETE

Créer un livre
NOK : GET http://frebourg.ninja/books/create
OK : POST http://frebourg.ninja/books

Affiche
NOK : GET http://frebourg.ninja/books/display/87
OK : GET http://frebourg.ninja/books/87

Mettre à jour
NOK : POST http://frebourg.ninja/books/editer/87
OK : PUT http://frebourg.ninja/books/87

Supprimer
NOK : GET http://frebourg.ninja/books/87/delete
OK : DELETE http://frebourg.ninja/books/87

Le serveur peut renvoyer les opérations acceptées sur une ressource via l’entête HTTP Allow.

Règle n°3 : les réponses HTTP comme représentation des ressources

Le client définit le format qu’il souhaite via l’entête HTTP Accept

Réponse en HTML
GET /books
Host: frebourg.ninja
Accept: text/html

Réponse en JSON
GET /books
Host: frebourg.ninja
Accept: application/json

Règle n°4 : les liens comme relation entre ressources

L’attribut rel dans la réponse permet de connaitre les relations entre ressources. On parle d’hypermédias.
Exemple de réponse en JSON d’une liste paginée de livres :

« books »:[ { rel »: « self », « href »: « http://frebourg.ninja/books?q=policier&page=1&c=5 »} ,{« rel »: « next », « href »: « http://frebourg.ninja/books?q=policier&page=2&c=5 »}]

Règle n°5 : un paramètre comme jeton d’authentification

On authentifie une requête grâce au jeton qu’elle renvoie. Ce jeton est élaboré grâce à un premier jeton envoyé par le client et une génération coté serveur par des méthodes de cryptage.

 

 

Le modèle de maturité de Richardson

Le modèle de maturité de Richardson est un moyen d’évaluer votre API par rapport aux contraintes de REST. Plus votre API respecte ces contraintes, plus haut est son score. Le modèle de maturité de Richardson compte 4 niveaux (0-3), où le niveau 3 représente une vraie API RESTful.

Niveau 0 : Basiquement XML

Le niveau 0 utilise son protocole d’implémentation (généralement HTTP, mais ce n’est pas une obligation) comme protocole de transport. Dans les faits, il tunnelise les requêtes et les réponses au travers de son protocole sans utiliser ce protocole pour indiquer l’état de l’application. Des exemples sont SOAP et XML-RPC. Une seule URI et un seul verbe HTTP.

Niveau 1 : Ressources

Lorsque votre API permet de distinguer différentes ressources, elle peut être de niveau 1. Ce niveau utilise plusieurs URIs.

Niveau 2 : Verbes HTTP

Ce niveau précise que votre API devra utiliser les propriétés du protocole afin de pouvoir évoluer et résister aux pannes. Plusieurs verbes et les codes de réponse du protocole HTTP. Par exemple, n’utilisez pas le code [200] (OK) lorsque quelque chose se passe mal.

Niveau 3 : Contrôles Hypermédia

Le niveau 3, qui est le plus haut niveau, utilise HATEOAS pour permettre aux clients de découvrir les possibilités de votre API. Pour une API HATEOAS, il est nécessaire de connaitre les ressources liées à celle obtenue pour pouvoir par exemple naviguer entre elles. Les contrôles hypermédia permettent d’obtenir ces informations. Malheureusement, JSON ne possède pas de normalisation à ce sujet et OPEN API n’a apparemment pas statué sur une structure d’Hypermédia.

2018-07-19T22:28:25+00:00By |Tags: |

Leave A Comment