Comme d'habitude, donnons une définition sémantique de la "compatibilité descendante" avant de commencer la présentation.
La rétrocompatibilité est la propriété de l'ensemble du système d'API d'être stable dans le temps. Cela signifie ce qui suit: le code écrit par les développeurs à l'aide de votre API continue de fonctionner correctement pendant longtemps . Il y a deux grandes questions à cette définition et deux éclaircissements.
Que signifie «fonctionnellement correct»?
Cela signifie que le code continue de remplir sa fonction - pour résoudre une tâche utilisateur. Cela ne signifie pas que cela continue à fonctionner de la même manière: par exemple, si vous fournissez une bibliothèque d'interface utilisateur, la modification des détails de conception fonctionnellement non pertinents, tels que la profondeur de l'ombre ou la forme du contour de la bordure, ne rompra pas la rétrocompatibilité. Mais, par exemple, la modification de la taille des composants visuels est susceptible de conduire au fait que certaines mises en page personnalisées se désagrègent.
Que signifie «long time»?
De notre point de vue, la durée du maintien de la rétrocompatibilité doit être liée à la durée des cycles de vie des applications dans le domaine correspondant. Dans la plupart des cas, les périodes LTS des plates-formes constituent une bonne ligne directrice. Étant donné que l'application sera toujours réécrite en raison de la fin du support de la plate-forme, il est normal de suggérer également de passer à une nouvelle version de l'API. Dans les principaux domaines (systèmes d'exploitation desktop et mobiles), cette période est calculée sur plusieurs années.
La raison pour laquelle la compatibilité descendante doit être maintenue (y compris la prise des mesures nécessaires au stade de la conception de l'API) ressort clairement de la définition. La résiliation de l'application (totale ou partielle) due à la faute du fournisseur d'API est un événement extrêmement désagréable, voire un désastre, pour tout développeur, surtout s'il paie de l'argent pour cette API.
: ? ? , , , .
, API. : , , . , , , , API, :
, , , ;
: , ;
, API , .
« API », . : API , , API — — .
NB: : « » API.
, API — , . , : - — , , . : , , .
API, : , .
, API, — . , . :
on-demand , - , ( SDK, , JS API), API . , - .
, — SDK . , on-demand — , , . , ( ) SDK. , - , API .
on-demand , , . , — «» , API, , . , Web-; , — :
- , ;
- ( , , , «» );
, .
. , API — , API.
SDK, API , , HTTP . , , API - SDK, . : SDK — SDK ( - ), . « — », , : API — , API . , , API .
, API stateless SDK ( SDK ), , — API. - API SDK.
— , API. , , - :
- ;
- ;
- .
, API . API - , API, , — . , — , , .
, API , , , () . , API , , , .
, — «», API. , , , , . , , , SDK. , , .
, , ( API) , , .
, API , . , — , , , . «» , API.
, :
- , API, ; , , ;
- API ;
- , API .
.
API.
. API , , . , , . , . , , ( ), , .
.
, : . 5-10 , — , . , .
( ) .
:
- API SDK, API, : API , ;
- code-on-demand SDK, SDK , , - . , , .
Nous examinerons ces questions plus en détail dans les chapitres suivants. En outre, dans la section III, nous discuterons également de la manière d'alerter les consommateurs sur les nouvelles versions et la fin du support, et sur la manière de les encourager à migrer vers des versions d'API plus récentes.
Ceci est un brouillon pour un prochain chapitre du livre sur le développement d'API. Le travail se fait sur Github .
La version anglaise du même chapitre est publiée sur support . J'apprécierais que vous puissiez le partager sur reddit - je ne peux pas moi-même selon la politique de la plate-forme.