Architecture d’une API Web

De nos jours, rares sont les services Web n’offrant pas d’Application Programming Interface (API).

Parmi les plus populaires on retrouve Google, Facebook, GitHub, LinkedIn, Twitter ou encore Microsoft. Mais qu’est-ce réellement une API? C’est simplement une façon d’échanger des données  entre des applications. Par opposition à un site web classique, où les données sont formatées de façon à ce que le contenu soit facilement interprétable par un humain (HTML, CSS), avec une API on cherche un moyen de communiquer qui soit facile pour une machine.

Parmi les technologies disponibles pour arriver à ce but, on entend souvent parler de SOAP et REST. Qu’est-ce que ces deux termes signifient? Comment architecturer une API Web moderne? Ce sont les questions auxquelles nous allons répondre dans cette article.

Avant de rentrer dans le vif du sujet, il est important de noter que SOAP désigne un protocol alors que REST est un style architectural. Il faut donc rester prudent en les comparant.SOAP, pour Simple Object Access Protocol, est un protocol inventé par Microsoft en 1998 qui permet l’échange d’information structurées à travers le réseau en utilisant le format XML. Contrairement à REST, il n’expose pas les données, mais les opérations possibles sur celles-ci. Cela fournit une interface au client afin de lui permettre d’accéder à la logique métier du service. Par exemple :

      getUser(User)
      orderItem(User, Item)

Pour transmette les interfaces offertes par le web service de manière générique, SOAP propose WSDL (Web Service Description Language). Il s’agit d’un langage reposant sur XML qui permet de décrire les opérations disponibles. La nature structurée de ce dernier permet de générer facilement un client capable d’interroger cette API. En outre, SOAP offre de nombreuses extensions, telles que WS-Security, WS-AtomicTransaction ou encore WS-Federation. Ce qu’il faut retenir de tout ça, c’est que ce protocole est très complexe et parfois difficile à utiliser, mais offre énormément de flexibilité et n’est pas seulement lié à HTTP, il peut aussi fonctionner avec d’autres protocoles tels que SMTP.

Comme nous l’avons mentionné précédemment, REST, qui est l’acronyme de Representational State Transfer, est un style architectural. Il a été créé par Roy Fielding en 2000 et définit un ensemble de contraintes pour construire une API. L’élément de base de REST est appelé ressource. Cette dernière peut faire référence à n’importe quelle entité accessible et/ou manipulable via l’API : un utilisateur, un produit, une image, etc. Chaque ressource est identifiée par une URI (Uniform Resource Identifier) et, afin de  pouvoir être transmise sur le réseau, est sérialisée dans un format de données, généralement JSON ou XML. Pour un exemple plus concret de ce qu’est une API REST, vous pouvez consulter l’article « Introduction à l’architecture REST » sur notre blog.

Bien qu’il ne fait pas de sens de directement comparer SOAP et REST, on peut tout de même noter quelques distinctions :

  • REST offre par design une plus grande scalabilité ainsi que de meilleures performances grâce notamment au caching et à l’utilisation de formats plus efficace qu’XML (e.g. JSON).
  • REST est beaucoup plus simple et beaucoup plus léger.
  • Le développement d’une application Web en JavaScript est beaucoup plus simple et léger avec REST qu’avec SOAP.
  • SOAP est standardisé et fournit un grand nombre d’extensions qui le sont elles aussi.
  • SOAP permet de facilement générer des clients pour une API grace à WSDL.

Abordons à présent la problèmatique de l’architecture d’une API. Que l’on utilise l’une ou l’autre des technologies présentées précédemment, il y a un certains nombre de points à prendre en compte lors de la conception d’une API Web :

  • L’API doit être entièrement documentée avec des exemples et bien sûr être toujours à jour.
  • Pour de nombreux cas, il est difficile de prévoir la croissance en terme de trafic que l’API va connaître. Il est donc nécessaire de garder à l’esprit que l’API doit être scalable si le besoin s’en fait sentir.
  • La sécurité est également importante. On expose à travers l’API des informations potentiellement sensibles. Il faut impérativement restreindre l’accès à chaque données/opérations aux seules personnes y ayant droit.
  • Il faut aussi être robuste face aux erreurs. Un crash ou une erreur qui se produit côté serveur, ne doit pas impacter l’utilisation du service. Par exemple, une exception qui est levée ne doit pas rendre ce dernier inaccessible.

En conclusion, avec l’avènement des applications web, les APIs sont devenues monnaie courrante. Elles sont égalements très utilisées pour connecter les applications mobiles (Android, iOS, …) à un service. Avec une telle sollicitation, il est devenu essentiel d’utiliser les bonnes technologies pour son API ainsi que de bien architecturer cette dernière. Pour cela, deux courants dominent le marché : SOAP et REST.

Il serait incorrect de dire que l’un est meilleur que l’autre. Tous deux ont leurs avantages et inconvénients, cependant la tendance actuelle va très clairement en direction de REST plutôt que SOAP. En effet, la plupart des grands acteurs du web (Google, Amazon, Twitter, LinkedIn, GitHub, Facebook etc.) ont tous fait le choix d’opter pour ce style d’architecture. Il ne faut cependant pas rester fermé et garder à l’esprit que SOAP est toujours encore bien présent dans l’industrie et que dans certains cas son utilisation offre plus d’avantages que REST.

Laisser un commentaire