19 Oct 2012, 10:09
Défaut:
by

2 comments

Architectures logicielles et APIs Hypermédias

Concevoir une architecture hypermedia distribuée requiert de se placer dans une perspective très simple où c’est l’échange entre le serveur et le client qui focalise les décisions d’architecture.

En l’occurence, si l’on parle d’APIs Web, cela suppose une bonne connaissance de HTTP d’une part, et une bonne connaissance des MediaTypes qui seront utilisés d’autre part.

Cela veut dire qu’il faut se focaliser sur les messages que s’échangent le client et le serveur. Ce que le client ou le serveur font par ailleurs de ces messages échangés est secondaire.

C’est la raison pour laquelle les enjeux de conception d’architectures logicielles distribuées sont totalement découplés du choix ou de l’utilisation d’un langage de programmation.

Dans la réalité, il me semble que bien souvent on raisonne de la manière suivante :

  1. On commence par le langage de développement (on ne le choisit pas car on part avec celui que l’on connaît) ;
  2. Ensuite on parle de framework (on utilise des frameworks qui facilitent le travail mais qui occultent les choix architecturaux implicites de ces frameworks) ;
  3. Enfin, on se pose des questions d’architecture, voire de style d’architecture.

Raisonner de la sorte est souvent révélateur de deux choses :

  • Une ignorance de HTTP, ce qui est quand même gênant pour faire des APIs Web
  • Une méconnaissance des enjeux des MediaType (le choix d’un type de format d’échange se résume souvent à utiliser celui qu’on connaît déjà, ou alors d’en utiliser un dont on parle beaucoup et qui est à la mode)

Au final, les questions d’architecture et de style d’architecture logicielle ne sont pas posées, le langage de programmation et les frameworks auront répondus avant même que la question soit posée.

On se retrouve donc dans la situation suivante :

  1. Soit il y a un primat du serveur, c’est le monde des serveurs d’application (en plus du serveur d’application qu’est déjà un serveur web).
  2. Soit il y a un primat du client, c’est le monde les développeur front-end dominé par les questions relatives à un seul type de client qu’est le Navigateur Web (je n’occulte pas le fait qu’il y a plusieurs navigateurs et que les appareils mobiles complexifient encore la donne).

En ce qui concerne les API Hypermedia, il faut renvoyer dos à dos ces approches orientées « serveur » ou « client », c’est la relation client-serveur et les messages échangés qui doit primer.

S’il faut parler de programmation, on dira plutôt qu’il s’agit de programmer le réseau, la relation client-serveur elle-même, ce qui n’est pas la même chose que programmer le serveur ou le client.

Merci pour ce billet. J’ai l’impression qu’il prolonge une esquisse de discussion entendue lors d’une récente réunion 😉

[Reply]

Très intéressant. Je réfléchi justement en ce sens depuis quelque temps. Penser « mobile app first » nous force jusqu’à un certain point à réfléchir aux données et messages communiqués entre client et serveur, qui sont en général très semblables pour un site Web. Les framework nous ont malheureusement habitués à penser « tout construire côté serveur » et nous sommes aussi habitués à vouloir trop contrôler l’expérience utilisateur et y inscrire un cadre fixe.

[Reply]

 

Laisser un commentaire

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.