Le principe du pattern “OpenAPI” consiste à développer et exposer des services utilisables par des tiers, sans avoir d’idée préconçue sur l’usage qui en sera fait.
Le développement porte donc essentiellement sur la logique applicative et le système de persistance. L’interface et la logique métier seront développées par des tiers, peut être plus experts dans les technologies d’interface et les problématiques ergonomiques, des métiers spécifiques, etc. (dans ce sens, voir l’histoire de l’écosystème Twitter à cette adresse).
Le moteur de l’application expose donc une API[1], c’est à dire un ensemble de services. L’application finale reposera sur la composition du service avec d’éventuels autres services fournis par des tiers. C’est par exemple le cas avec HousingMaps.com : le site permet visualiser les petites annonces issues du service CraigsList.org au travers du service Google Maps.
Le pattern rejoint ainsi les principes majeurs des architectures SOA[2] : le découplage, et la possibilité de composition. Pendant un temps, on a opposé les architectures des grands du Web, généralement basées sur le style REST[3], aux architectures SOA d’entreprises, souvent basées sur le protocole SOAP [4]. De nombreux bloggeurs ont polémiqué sur l’opposition entre ces deux architectures. Nous pensons de notre côté que les API REST exposées par les grands du Web sont une forme parmi d’autres d’architecture SOA.
Les grands du Web exposent leurs API publiquement, créant des écosystèmes ouverts. Cette stratégie leur permet de :
Marc Andreessen, créateur de Netscape, distingue trois types de plateformes ouvertes :
Notons aussi que les API des grands du web sont accessibles en self service, c’est à dire que la souscription peut se faire depuis le site Web sans aucune relation commerciale avec le fournisseur.
Au niveau 3, il est nécessaire de concevoir un système multi-tenant (multi-locataire, en français). Son principe est de gérer de manière isolée les applications de plusieurs entreprises avec un équilibre entre mutualisation et isolation.
Le pattern « API First » est un dérivé du Pattern « OpenAPI » : il suggère de commencer par bâtir une API, puis de la consommer pour construire les applications destinées aux utilisateurs finaux. L’idée est se mettre au même niveau que les utilisateurs de l’écosystème, donc à s’appliquer à soi même les principes d’architecture qu’on propose à ses clients, selon le pattern « eat your dog’s food » (EYODF). Un certain nombre d’architectes chez les grands du Web considèrent que c’est la meilleure manière de bâtir une nouvelle plateforme.
Dans la pratique, le pattern API First représente un idéal pas toujours appliqué : dans l’histoire récente, il semble qu’il aurait été appliqué pour Google Maps ou Google Wave, services tous deux développés par Lars Rasmussen. Par contre, il n’a pas été appliqué pour Google+, ce qui a provoqué le courroux de nombreux bloggers.
Quasiment tout le monde finalement…
L’API de Google Maps est très fameuse : elle est, avec celle de Twitter, l’une des plus utilisée par les sites Web selon programmableweb.com. Elle est devenue le standard de facto pour exposer des objets sur un fond de carte. Elle utilise des jetons d’authentification (client ID) afin de mesurer la consommation d’une application donnée, et de pouvoir la facturer au delà d’un certain quota.
L’API de Twitter est très largement utilisée : elle propose des services sophistiqués pour accéder aux données des abonnés en lecture, en écriture. Il est même possible de l’utiliser en streaming pour recevoir les mises à jours de Tweets au fil de l’eau. Toutes les fonctionnalités du site, sont accessibles via l’API. L’API offre aussi un système de délégation de droit d’accès (basé sur le protocole OAuth) qui permet d’autoriser une application tierce à twitter en votre nom.
Le service de cartographie Mappy propose des APIs de geocoding, calcul d’itinéraire, etc. disponibles sur api.mappy.com
Orange propose avec api.orange.com la possibilité d’envoyer des SMS, de géolocaliser des abonnés, etc.
Le pattern OpenAPI est à envisager dès lors qu’on souhaite créer un écosystème ouvert à des partenaires ou clients, internes ou externes. Cet écosystème peut être ouvert sur Internet ou limité à un usage interne à l‘entreprise.
Un cas relativement classique en entreprise est l’exposition de l’annuaire des collaborateurs pour permettent l’intégration de leurs identités dans les applications.
Un autre cas classique est l’intégration de services exposés par des fournisseurs (par exemple une banque consomme les services d’une société d’assurance).
Enfin, un cas d’usage moins classique consisterait à ouvrir une plateforme pour ses clients finaux :
Pattern “Device Agnostic” (billet à venir)
Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"
Style REST (Representational State Transfer)
Livre "SOA, Le guide de l'architecte d'un SI agile"
Plateformes ouvertes selon Marc Andreessen
[1] Application Programming Interface
[2] Service Oriented Architecture
[3] Representational State Transfer
[4] Simple Object Access Protocol