"Les API publiques sont éternelles: une seule chance de bien faire les choses"?


20

Dans un livre sur le système d'exploitation, je viens de lire que "les API publiques sont éternelles: une seule chance de bien faire les choses". Est-ce vrai? Est-il applicable uniquement dans les API des systèmes d'exploitation ou dans d'autres API? Par exemple, cela sera-t-il vrai pour les API des applications Android telles que Tasker, Locale et Pushover?


2
J'étendrais le principe à tout le code. Il n'y a tout simplement pas assez de temps pour écrire plusieurs fois la même chose. Écrire du code parfait est une compétence qui peut être apprise.
tp1

22
@ tp1: écrire du code parfait est une compétence qui n'existe pas dans le monde réel.
Michael Borgwardt

4
@michael borgwardt: Il suffit de choisir la version parfaite à utiliser.
tp1

1
J'ai vu cela dans le monde réel, et cela dépend de quel type d'API. Leçon apprise: la première exigence de toute API Web "accessible au public" est la possibilité pour l'utilisateur de l'API de sélectionner la version de l'API qu'il utilisera.
Josh Petitt le

Réponses:


32

C'est généralement vrai pour toute API publique, oui. Une fois que vous exposez une API au public et que les gens commencent à créer des applications qui dépendent de cette API, il devient extrêmement difficile de changer l'API, car cela casserait toutes ces applications. Cela a tendance à être à la fois un problème technique difficile et un problème politique difficile.

Bien sûr, il est possible de changer une API publique. Il arrive, par exemple, que des projets suppriment une API dans une version, introduisent une nouvelle API, puis suppriment l'ancienne API dans une version future. Mais cela suppose que chaque application (importante) qui utilise l'ancienne API sera réécrite pour utiliser la nouvelle API avant la suppression de l'ancienne API. Cela prend souvent plusieurs années. Et cela signifie que le propriétaire de l'API publique impose un coût à tous les autres projets qui utilisent l'API. Puisqu'il y a généralement beaucoup plus de consommateurs d'une API, ces consommateurs ont tendance à être un lobby politique relativement puissant.


2
"à la fois un problème technique difficile et un problème technique difficile" Vous avez répété "technique" deux fois.
luiscubal

12
@luiscubal: c'est parce que c'est vraiment un problème technique sacrément difficile.
Michael Borgwardt

3
@luiscubal Vous voulez dire une fois. Répété une fois, dit deux fois.
Joe Z.

4
"Les réponses publiques ne sont pas éternelles ..."
Chris

3
@Chris Pas vraiment. La réponse de Justin n'est plus compatible avec le commentaire de Luiscubal. :-)
svick

12

L'auteur de la citation est Joshua Bloch, la déclaration provient de son article sur la conception de l'API Bumper-Sticker :

Les API publiques, comme les diamants, sont éternelles. Vous avez une chance de bien faire les choses, alors faites de votre mieux.

Pour plus de détails à ce sujet, l'auteur renvoie les lecteurs à sa présentation de session de conférence, "Comment concevoir une bonne API et pourquoi c'est important" . Slide Why is API Design Important to You indique assez clairement que cela est pertinent pour toute activité de programmation (systèmes d'exploitation ou non, peu importe l'auteur):

  • Si vous programmez, vous êtes concepteur d'API

    • Le bon code est modulaire - chaque module a une API
  • Les modules utiles ont tendance à être réutilisés

    • Une fois que le module a des utilisateurs, ne peut pas changer d'API à volonté
    • Les bons modules réutilisables sont des actifs de l'entreprise
  • Penser en termes d'API améliore la qualité du code

La conclusion de la diapositive souligne également cela comme une approche générale:

  • La conception de l'API est un métier noble et gratifiant

    • Améliore le sort des programmeurs, utilisateurs finaux, entreprises ...

2
Techniquement, le diamant est métastable. Thermodynamiquement parlant, le graphite est une forme de carbone plus stable.
Détly le

3

Les API changent toujours, sinon à quoi servirait la mise à niveau du système? Changer les internes uniquement?

Chaque version du système apporte de nouvelles API, les anciennes API deviennent obsolètes et les API obsolètes disparaissent.

Le changement d'API doit seulement être très prudent à la fois techniquement et en termes de communication.


Tant que vous pouvez bien communiquer avec tous vos consommateurs et qu'ils peuvent parler à leurs utilisateurs - regardez Windows: Windows a des tonnes de vieilles API, obsolètes et mauvaises, car les utilisateurs finaux aiment exécuter des applications extrêmement anciennes même sur des systèmes modernes
johannes

2

Mon opinion serait qu'une fois publiée, cette `` version '' de l'API est éternelle, mais vous pouvez la déprécier en publiant une API `` 2.0 '' (il existe plusieurs exemples où cela se produit - actuellement, je peux penser à Strava qui a publié une version 2.0 d'une API de développement contre pour consommer leurs services).

Le problème est de supporter cette API d'origine à l'infini ... Je suppose que cela dépend de l'utilisation de l'ancienne API et de la valeur que ces consommateurs d'API vous réservent.

Pour en revenir à «l'ancien temps» de Windows 3.x et 9x, par exemple, une fois la version publiée, ces API de système d'exploitation ont été définies et définies. Maintenant, les mises à jour du système d'exploitation sont poussées tout le temps, de sorte que de nouvelles API peuvent être publiées, mais je pense que tant que vous exécutez une saveur de système d'exploitation particulière (version majeure), ces API ne seront ajoutées qu'à, jamais supprimées ... peut-être pas être le cas pour la «prochaine» version majeure.

Hmm, je me suis peut-être éloigné de l'intention de la question d'origine.


1

Cela dépend de quel type d'API il s'agit (et je suppose que des changements de rupture, sinon l'affirmation n'est évidemment pas vraie).

Si l'appelant peut choisir la version qu'il utilise (par exemple avec les bibliothèques / frameworks fournis avec l'application appelante), alors changer l'API n'est pas un problème énorme - mais toujours mauvais pour la réputation du logiciel. Les gens aiment mettre à niveau en toute transparence.

D'un autre côté, lorsque les gens ne peuvent pas continuer à utiliser l'ancienne version de l'API (comme avec un service en ligne, ou des choses comme un navigateur ou un système d'exploitation où l'exécution d'anciennes versions est très indésirable), alors changer les API de manière incompatible est très mauvais en effet, car il cassera tous les logiciels qui l'utilisent et n'est pas mis à jour également. Cela impose un coût de maintenance aux développeurs, et ils vous détesteront pour cela. Et les logiciels qui ne sont pas maintenus et qui se cassent vous feront aussi très mal.

D'un autre côté, il y a au moins un fournisseur d'API qui introduit constamment des changements de rupture dans l'API et qui a tout de même un succès ridicule: Facebook. Mais ils gèrent les changements très soigneusement: il y a une politique publiée , les changements de rupture sont annoncés et expliqués au moins 90 jours à l'avance, et les développeurs peuvent choisir de les activer tôt dans ce délai.


1

Si vous avez la prévoyance d'inclure un numéro de version dans l'API elle-même. Soit lors de l'appel de connexion / initialisation, soit quelque part près du début de la liste des paramètres de chaque appel, votre API peut évoluer et muter au fil du temps sans perturber les clients existants.


0

Bien que tout ce que nous faisons est de les améliorer d'un seul coup, mais depuis que le temps change et s'améliore, nous devons parfois mettre à jour les informations, comme l'ont fait de nombreux fournisseurs géants (comme Face Book plusieurs mises à jour, Twitter One Major) se tourner vers oAuth et plusieurs grands, mais dans la mesure du possible, tout vient avec une amélioration donc pas de changements fréquents.


-1

Chaque fois que vous publiez une sorte de protocole de communication, qui comprendrait évidemment une API, vous avez une chance de bien faire les choses dans le sens où le protocole / l'interface doit être rétrocompatible et extensible.

Cela vous permet d'ajouter de nouvelles fonctionnalités et de publier de nouvelles versions sans avoir à vous soucier de casser les personnes qui utilisent des versions plus anciennes. Jamais dans le monde du logiciel, vous n'aurez une situation où vous pouvez simplement avoir un basculement dur à un certain moment, et tout le monde abandonne l'ancienne version et commence à utiliser la nouvelle version.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.