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

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?

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.

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 ...

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.

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.

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.

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.

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.

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.