Les Patterns des Grands du Web : « OpenAPI » ou écosystème ouvert

Description du pattern

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 :

• Créer des revenus directs, en les facturant. Par exemple : Google Maps devient payant au delà de 25 000 transactions par jour.
• Étendre une communauté, et donc recruter des utilisateurs. Exemple : grâce aux applications dérivées de sa plateforme, Twitter a atteint 140 millions d’utilisateurs actifs (et 500 millions d'inscrits).
• Faire émerger de nouveaux usages pour sa plateforme et donc faire évoluer son modèle de revenu. Exemple : En 2009, Apple a constaté que les développeurs d’applications souhaitaient vendre non seulement des applications, mais aussi des contenus pour leurs applications. Le modèle de l’AppStore a donc évolué pour intégrer cette possibilité.
• Parfois, externaliser leur  R&D, puis racheter les startups les plus talentueuses. C’est ce qu’a fait Salesforce avec Financialforce.com

Marc Andreessen, créateur de Netscape, distingue trois types de plateformes ouvertes :

• Niveau 1  « Access API » : ces plateformes permettent l’appel à un traitement métier sans fourniture d’interface homme/machine. Exemples : recherche de livres chez Amazon, geocoding chez Mappy.
• Niveau  2   « Plug-In API » : Ces plateformes permettent d’intégrer une application à l’interface du fournisseur. Exemple : les applications Facebook, les Widgets Netvibes.
• Niveau  3   « Runtime Environment » : Ces plateformes fournissent non seulement une API, une interface, mais aussi un environnement d’exécution. Exemple : les applications AppExchange dans l’écosystème Salesfoce ou l’iPhone.

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.

Chez qui ça fonctionne ?

Quasiment tout le monde finalement…

Les références chez les grands du Web

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.

En France

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.

Et chez moi ?

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 :

• Une banque permettrait à ses clients d’accéder à l’ensemble de leurs transactions : voir l'exemple d'AXA.
• Un opérateur télécom ou un fournisseur d’énergie permettraient à leurs clients de d’accéder à leur encourt de consommation

Dépendances à d'autres patterns

Pattern “Device Agnostic” (billet à venir)

Exceptions

• Tout ce qui nécessite un workflow complexe
• L’informatique temps réel (type avion, automobile, machine outil) : dans ce cas, la composition de services peut poser des problèmes de performance.
• La manipulation de données posant des problématiques réglementaires : il est peu souhaitable de faire transiter des données critiques entre plusieurs plateformes.

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"

Sources

Style REST (Representational State Transfer)

Architectures SOA

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