SOA vs REST

les noms d’emplacements Web (choses) de préférence aux interfaces plus créatives de SOA (Service Oriented Architecture) orientées service.

En effet, il me semble que les interfaces SOA (spécifiées par *.wsdl) tendent vers une complexité excessive et donc sont trop restrictives pour des contextes « mash-up » allant bien au-delà de l’intention originale de l’auteur. Par exemple, les interfaces SOA qui sont « soudées » aux applications non- Web aboutissent souvent à des API clients telles que getNbrLargeUsersRidingMopeds (int country, int height, int weight, long horsepower, int mpg, int avgPrice, string fuzzySearchWords).

Une telle API est beaucoup trop longue pour une réponse sous forme d’entier simple. De plus, elle est d’une valeur « mash-up » limitée au-delà du domaine original prévu par l’auteur. Toutes les interfaces basées sur SOA ne sont pas aussi extrêmes que cet exemple : elles peuvent aussi être naturelles pour le Web et polyvalentes. J’observe simplement que les interfaces REST semblent conduire les auteurs Web vers des services facilement consommables. Le « mash-up » est l’action qui consiste à intégrer des données provenant de multiples sources, dans un nouveau contexte Web.

Ainsi, si le site A offre des tarifs aériens réduits à certaines dates et si le site B offre des tarifs d’hôtel réduits à certaines dates, le développeur mash-up astucieux peut mêler les données des deux sites pour en créer un troisième qui combine les dates de tarifs aériens et de tarifs hôteliers réduits.

Astuce : Si vous envisagez d’utiliser des interfaces de type SOA sur votre site, je vous conseille de réaliser d’abord une maquette du jeu d’API du site en utilisant les idées REST (sur papier, si non en code réel). Tout d’abord, cela oblige l’auteur à penser en termes de noms bookmark Web (choses).

Deuxièmement, le jeu de verbes REST est petit (quatre verbes), ce qui tend à écarter des interfaces trop finement spécifiées, et donc rend les API moins complexes. L’exemple serveur et client REST qui suit ne doit pas être utilisé comme ébauche d’une programmation Web, mais plutôt comme un outil pédagogique pour bien montrer les différences entre les structures de langages Net.Data et PHP. Si vous voulez approfondir le débat entre SOA et REST, lisez donc les nombreux articles et blogues proposés en ligne. Dans les exemples qui suivent, nous mélangerons les clients et serveurs REST multilangages pour démontrer non seulement les différences entre Net.Data et PHP, mais aussi comment ces deux langages peuvent collaborer.

La composante Net.Data de l’exemple sera hébergée sur le port 80 du HTTP traditionnel par Apache, et la composante PHP de l’exemple sera hébergée à partir du port 8000 de Zend Core for i5/OS Apache (figure 5). A noter que selon la version de Zend Core for i5/OS utilisée, la configuration par défaut peut utiliser le port 89 (lequel est un proxy reverse du port 8000).