As usual, we will give a semantic definition of "backward compatibility" before starting the presentation.
Backward compatibility is the property of the entire API system to be stable over time. This means the following: code written by developers using your API continues to function correctly for a long time . There are two big questions to this definition, and two clarifications to them.
What does "functionally correct" mean?
This means that the code continues to perform its function - to solve some user task. This does not mean that it continues to work the same: for example, if you provide a UI library, then changing functionally irrelevant design details, such as shadow depth or border stroke shape, will not break backward compatibility. But, for example, resizing the visual components is likely to cause some custom layouts to fall apart.
What does “long time” mean?
From our point of view, the duration of maintaining backward compatibility should be linked to the duration of the life cycles of applications in the corresponding subject area. A good guideline in most cases is the LTS periods of the platforms. Since the application will still be rewritten due to the end of platform support, it is normal to suggest switching to a new version of the API as well. In the main subject areas (desktop and mobile operating systems), this period is calculated in several years.
Why backward compatibility needs to be maintained (including taking the necessary measures at the API design stage) is clear from the definition. The termination of the application (full or partial) due to the fault of the API provider is an extremely unpleasant event, if not a disaster, for any developer, especially if he pays money for this 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 , , - . , , .
We will explore these issues in more detail in the following chapters. Additionally, in Section III, we will also discuss how to alert consumers to newer versions and end of support, and how to encourage them to migrate to newer API versions.
This is a draft for a future chapter of the book on API development. The work is done on Github .
The English version of the same chapter is published on medium . I would appreciate it if you can share it on reddit - I myself cannot according to platform policy.