Services Web ou API ?

Web service & APIs

On ne parle plus beaucoup de « services web » pour désigner les communications de machines à machines sur le web. On préfère mettre en avant le terme d’API : par exemple on ne dit plus « Restful web services » mais « Restful API« .

Qu’est ce qui a changé ?

A part que cela permet à O’reilly et d’autres de rééditer les mêmes livres en changeant le titre, il n’y a apparemment pas grand chose de nouveau.

D’un point de vue générique, un service web est une API (une API qui a la particularité d’utiliser le protocole HTTP) ; et une API web serait alors  le mécanisme que connaissent les développeurs (librairies, modules, classes, etc.) mais appliqué au protocole HTTP.

Interface ou Protocole ?

Les choses paraissent donc simples, mais elles ne le sont pas forcément si on y prête bien attention.

Il se trouve que HTTP, en tant que protocole de transfert, est également qualifié d’ « Interface », au sens ou Roy Fielding parle de “Uniform Interface” quand il décrit les 4 sous- principes du style REST :

  • identification des ressources.
  • manipulation des ressources au travers de leurs représentations.
  • des messages auto-descriptifs.
  • l’hypermedia comme moteur des états applicatifs.

Ce qui est troublant, c’est donc que ce qui est explicitement un protocole (HTTP) soit en même temps qualifié d’interface. En effet, pour ceux qui ont le modèle OSI en tête, le terme d’interface était réservé à la communication entre des protocoles de niveaux différents sans qu’il n’y ait de protocole de transport utilisé.

Si les interfaces n’étaient pas des protocoles de communications, c’était parce que l’on considérait que le passage d’un niveau de protocole à un autre se faisait au sein de la même machine.

Voilà donc que ce qui semblait évident dans l’expression « API Web » devient tout à coup contradictoire : comment une interface (API) peut elle être en même temps un protocole (HTTP) ?

Une interface protocolaire est un protocole de transport qui devient un protocole de transfert

Une API web peut donc être comprise comme une “interface protocolaire”. Le génie du web est d’avoir permis une architecture qui supporte cette approche qui fait du protocole de transfert une interface.

C’est donc le protocole de transfert qui prime dans une API web. En fait nous pouvons aller plus loin en disant que les protocoles de transports deviennent des protocoles de transfert quand ils acquièrent un statut d’interface.

Le tunnelling HTTP des RPC était précisément une pratique qui consistait à ne pas considérer HTTP comme un protocole de transfert en l’utilisant comme un protocole de transport : cela permettait ainsi de travailler avec des API qui n’étaient pas web, notamment en considérant les représentations des ressources (les données) comme si on y accédait sans transport, comme avec une librairie de langage de développement qui irait chercher les données en mémoire ou sur le disque dur du serveur .

C’est cette sublimation d’un protocole de transport (TCP/IP) en une interface (uniforme ) qui donne des protocoles de transfert.

Économie des services web et économie des API

Ceux qui vendaient des architectures de services vendent à présent des architectures d’API.

Mais il y a maintenant quelque chose de différent en ce sens que c’était généralement les mêmes personnes qui mettaient en place les services web et qui les utilisaient. Dis autrement, c’était la même équipe qui étudiait les besoin de communication entre 2 ou n applications et mettaient en place les services web appropriés. Avec l’approche par les API la démarche est différente en ce sens que ce n’est pas forcément la même équipe de développeur qui produit les service web et les utilisent ; ce fait devient une évidence quand on ne parle plus d’API privées et interne mais d’API publiques.

Cette dissociation induit que les équipes qui conçoivent les services web ne seront pas forcément les mêmes qui vont les utiliser, d’où l’emphase sur les bonnes pratiques en matière d’API : simplicité, documentation,…

Comme le business des API est actuellement le plus florissant, il est donc nécessaire pour ceux qui y œuvrent de renouveler leur vocabulaire du service web vers un vocabulaire de  l’API dans une situation technologique qui n’a guerre évoluée depuis une douzaine d’années. Les technologies sont les mêmes , mais leurs pratiques et leurs implémentations sont différentes.

Comment le marketing technologique va-t-il souligner la différence entre les services web et les API ? Pour le dire rapidement, ce qui distingue une API d’un service web est que la première est un « contrat ». L’argument se justifie car tout transfert est un contrat (cf. la distinction entre technologies de transport et technologie de transfert ), et il faudra bien sûr en dire plus sur la nature et les enjeux de ce contrat.

L’emprise des phénomènes de mode et des buzzwords sur l’informatique m’a toujours frappé. Le « SOA » et les « services web » étant passés de mode (et on a vraiment abusé de ces termes il y a quelques années), voilà les APIs, qui vont bien dans le « Cloud »!
L’essentiel c’est finalement que tout le monde trouve le bon vocabulaire pour communiquer, travailler ensemble et finalement implémenter des systèmes informatiques robustes et conviviaux. Espérons que les « APIs » tiendront cette promesse.

[Reply]

Merci Christian de revenir sur REST, dont on ne soulignera jamais assez l’importance.

[Reply]

Salut et merci pour ces réflexions. Il doit y avoir un élément qui m’échappe car je ne comprends pas bien en quoi un service web serait moins un « contrat » qu’une API ?

[Reply]

[…] dit donnée dit généralement API, ou tout du moins service web : apprenons justement à faire la différence entre une API et un service web, qui peut être considéré comme une API utilisant le protocole web (HTTP). Le développement du […]

[…] dit donnée dit généralement API, ou tout du moins service web : apprenons justement à faire la différence entre une API et un service web, qui peut être considéré comme une API utilisant le protocole web (HTTP). Le développement du […]

[…] dit donnée dit généralement API, ou tout du moins service web : apprenons justement à faire la différence entre une API et un service web, qui peut être considéré comme une API utilisant le protocole web (HTTP). Le développement du […]

9 Sep 2015, 11:31
by Benoit LEGER-DERVILLE

reply

« Librairie » ou plutôt bibliothèque (en français) ? 🙂

[Reply]

3 Juil 2018, 1:20
by Benoît Rolland

reply

Utiliser un service REST pour donner accès à ses APIs est avant tout un moyen de protéger la valeur de son code,
en l’hébergeant à distance des utilisateurs,
là où il est plus difficile de protéger une bibliothèque et son API.

Reste que « Application Programming Interface » reste
une appellation assez surfaite,
étant donné les temps de réponse inhérents à la couche réseau.

[Reply]

 

Répondre à Thomas Francart Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.