L'avenir de la conception d'API: La couche d'orchestration

Advertisement

L'avenir de la conception d'API: La couche d'orchestration

Daniel Jacobson (LinkedIn), est actuellement directeur de l'ingénierie de l'API Netflix. Avant Netflix, Daniel a développé des applications pour NPR, entre autres, il a créé l'API NPR. Il est également co-auteur d'APIs: A Strategy Guide.


Le monde numérique se développe à un rythme étonnant, nous donnant accès à des applications et du contenu sur une myriade de périphériques connectés dans vos foyers, bureaux, voitures, poches et même sur votre corps. La colle qui permet à tout cela de se produire, qui relient les entreprises qui fournissent ces services aux dispositifs que vous utilisez, est l'API.

Parce que les API ont une telle responsabilité pour tant de gens et d'entreprises, il est naturel que la conception de l'API est souvent l'une des discussions les plus animées de l'industrie, touchant une gamme de sujets tels que la modélisation des ressources, le format de charge utile, la version du système et la sécurité .

Bien que ces domaines soient probablement importants à explorer lors de la conception de pratiquement n'importe quelle API, la réalité est qu'une décision beaucoup plus importante doit être faite en premier. Cette décision est basée sur une question fondamentale: qui sont les publics principaux pour cette API et comment pouvons-nous optimiser pour ces publics?

Cela semble une question assez inoffensive, mais ne sous-estimez pas son importance ou sa complexité dans le monde en plein essor des API.

Il ya des années, cette question était beaucoup plus simple

À cette époque, de nombreuses API émergentes étaient construites en tant qu'applications ouvertes ou publiques, ciblant un grand nombre de développeurs inconnus (LSUDs) externes à la société fournisseur.

En raison du nombre considérable de développeurs externes utilisant l'API représentant des cas d'utilisation différents, la façon la plus judicieuse de concevoir l'API pour ce public est de fournir à l'équipe d'API une conception très propre, concise et axée sur les ressources Qui représente de près le modèle de données et / ou les caractéristiques de sa (ses) source (s).

Dans un post précédent, je me suis référé à ces API OSFA (ou une taille unique pour toutes les API). Autoriser une telle granularité dans la modélisation signifie que tout développeur qui souhaite utiliser l'API peut mélanger et correspondre aux éléments de quelque manière qu'ils choisissent de satisfaire leur application sans participation supplémentaire de l'équipe API.

L'approche par modèle de ressources pour concevoir une API peut être très puissante, en particulier pour ce type de public. Le problème avec cette approche, cependant, est que la façon dont beaucoup d'entreprises utilisent aujourd'hui les API est différente de celle décrite ci-dessus. Bien que beaucoup soutiennent encore les cas d'utilisation de LSUD, plus sont en utilisant leurs APIs pour soutenir une croissance mobile ou stratégie de périphérique.

Pour certaines de ces implémentations, l'engagement avec les développeurs est différent. Le public est un petit ensemble de développeurs connus (SSKD) . Ils peuvent être des ingénieurs dans le couloir de l'équipe de l'API, une entreprise sous contrat engagé pour développer une application iPhone, ou une équipe d'ingénierie dans une société partenaire. Dans tous ces cas, cependant, l'équipe API sait qui sont ces personnes (au moins dans le sens abstrait).

Plus important encore, cependant, l'équipe de l'API et la société fournissant se soucient du succès de ces implémentations d'une manière différente de ce qu'ils pourraient se soucier des applications développées par les LSUD. En fait, le succès des SSKD peut très bien être primordial pour le succès de l'entreprise dans son ensemble, un modèle qui devient de plus en plus omniprésente.

En raison de ce changement d'audience et de l'intérêt profond pour leur succès, il ya une grande opportunité de changer la conception de l'API.

Pour les SSKD, avoir des API granulaires basées sur les ressources qui représentent étroitement le modèle de données fonctionne, mais il n'est tout simplement pas aussi optimale qu'elle pourrait l'être. C'est particulièrement le cas lorsque l'on considère le nombre croissant de types de périphériques dans le monde et le fait que de plus en plus de stratégies d'entreprise des entreprises dépendent de fournir de la valeur aux clients sur ces appareils.

Donc, il suffit d'un couple de périphériques avec des besoins divergents et / ou des capacités, chacune d'une grande importance pour l'entreprise, pour l'API basée sur les ressources pour commencer à montrer certaines verrues. Faire de l'API mieux, plus optimisé, pour chacune de ces applications cibles est la prochaine étape logique, et la plus critique.

Entrez la couche d'orchestration

Une couche d'orchestration d'API (OL) est une couche d'abstraction qui prend des éléments de données et / ou des caractéristiques généreusement modélisés et les prépare de manière plus spécifique à un développeur ou à une application ciblé

Pour saisir cette opportunité, de plus en plus d'entreprises utilisent des couches d'orchestration dans leur infrastructure API. Bien qu'il existe de nombreuses façons de mettre en œuvre cette construction architecturale, le concept reste le même pour tous.

Ci-dessous, je vais décrire quelques-uns des modèles les plus courants que j'ai vu (et / ou impliqué dans la mise en œuvre). Mais d'abord, voici quelques principes clés qui doivent être pris en compte lors de la construction d'un OL:

1. La plupart des API sont conçus par le fournisseur de l'API dans le but de maintenir la pureté du modèle de données. Lors de la construction d'une OL, soyez prêt à abandonner parfois la pureté en faveur d'optimisations et / ou de performances.

2. De nombreuses API sont conçues par des équipes API pour faciliter l'assistance de l'équipe API. Lors de la construction d'une OL, soyez prêt à ajouter de la complexité à l'équipe API (ou à d'autres équipes, selon la façon dont elle est implémentée).

Bien que cela semble indésirable, l'objectif ici est d'améliorer considérablement l'efficacité et / ou la simplicité pour d'autres personnes à un coût modéré pour l'équipe de l'API. Gardez également à l'esprit que ces coûts peuvent être programmés au fil du temps.

3. Il est important de comprendre l'ampleur des audiences de l'API. En fonction de ces constituants, vous n'aurez peut-être besoin que de la LO. Dans d'autres cas, vous pouvez avoir besoin de la fondation OSFA en plus de la LO.

Voici quelques exemples de la façon dont certaines LO ont été abordées:

Emballages spécifiques au périphérique

C'est le modèle le plus commun que j'ai vu parce que la plupart des entreprises qui connaissent la détresse mentionnée ci-dessus ont déjà des API qu'ils utilisent toujours, continuer à soutenir et à investir po Le résultat est de continuer à offrir les ressources granulaires comme ils ont toujours , Mais d'offrir un niveau de wrapper au-dessus d'eux - avec de nouveaux points d'extrémité qui sont adaptés à des développeurs spécifiques, des périphériques ou des clusters de périphériques.

Dans ce modèle, l'équipe API travaillera plus étroitement avec, par exemple, l'équipe iPhone pour écrire un wrapper personnalisé qui gère des demandes spécifiques et livrer des charges utiles spécifiques optimisées pour l'application iPhone. Dans ce modèle, le plus souvent l'équipe pour construire les noeuds finaux et les wrappers est l'équipe API bien que cela ne doive pas être le cas.

API basées sur les requêtes

Dans ce modèle, l'équipe API met le pouvoir entre les mains du développeur demandeur, bien que cette puissance soit limitée. L'objectif ici est de créer une méthode plus flexible pour que le demandeur puisse faire des demandes et adapter les charges utiles sans mettre un fardeau supplémentaire sur l'équipe de l'API, comme cela pourrait être le cas avec les wrappers spécifiques aux périphériques.

Cela est réalisé en décomposant les API basées sur les ressources et en leur permettant d'être interrogés comme une base de données grâce à des paramètres flexibles et des charges utiles qui peuvent se contracter, se développer et peut-être morph basé sur ce qui est nécessaire. L'avantage ici est qu'une fois que le langage de requête est défini, l'équipe de l'API n'a pas besoin de conserver des wrappers d'écriture car de nouvelles implémentations sont nécessaires pour différents périphériques.

Le préjudice, cependant, est que l'API basée sur la requête est toujours un ensemble de règles auxquelles le développeur doit adhérer, bien que ces règles soient beaucoup plus flexibles que le modèle d'API basé sur les ressources.

API basées sur l'expérience

L'avenir de la conception d'API: La couche d'orchestration

C'est le modèle que Netflix a mis en œuvre, qui, à certains égards, est un mélange des deux ci-dessus. Dans ce modèle, nous avons essentiellement des wrappers spécifiques aux périphériques, mais ils sont conçus, mis en œuvre et possédés par les équipes périphériques.

Un concept clé ici est que nous avons mis l'équipe API dans la position de rassembler les données d'une manière générique, réutilisable tout en mettant les équipes de périphériques dans la position de posséder le formatage des données et la livraison. Après tout, les besoins de mise en forme évoluent de concert avec les changements d'interface utilisateur afin de mettre cet effort dans les mains des personnes les plus proches des changements élimine les étapes supplémentaires.

(Pour plus de détails sur la façon dont ce système fonctionne, voir les liens en bas de la poste.)

Comme je l'ai mentionné, l'éventail des mises en œuvre est potentiellement beaucoup plus diversifié que ces trois, même si ce sont certains des modèles les plus cohérents et intéressants que j'ai vu. Indépendamment de la façon dont cela est réalisé, cependant, la clé est pour l'équipe de l'API d'arrêter de soutenir l'API comme un service qui est conçu indépendamment de ces SSKD qui le consomment.

L'équipe de l'API doit plutôt considérer les SSKD comme des partenaires dans la conception avec un intérêt à rendre les produits aussi grands que possible afin que les utilisateurs finaux puissent obtenir la meilleure expérience possible. L'équipe de l'API a la possibilité de créer des services qui aident les développeurs à être mieux à développer en se concentrant sur l'optimisation pour les besoins des développeurs plutôt que la façon d'optimiser le temps passé à supporter l'API.

Compte tenu de l'opportunité à venir avec le nombre potentiel et la diversité des périphériques connectés, l'effort pour fournir de telles optimisations est un petit prix à payer pour la hausse massive.

Pour plus d'informations sur le cas d'utilisation de Netflix, les problèmes rencontrés qui ont motivé notre refonte et la façon dont nous avons mis en œuvre notre API expérimentée, voici quelques liens:

  • Pourquoi le REST me maintient à la nuit
  • Reprendre les différences: à l'intérieur du Netflix API Redesign
  • Optimisation de l'API Netflix

Crédit d'image: bloomua / Shutterstock