books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-01-23 17:53:04 +02:00
Code Issues Releases Activity

Update 07.md

Browse Source 
typo
This commit is contained in:
Sergey Konstantinov 2022-05-20 12:27:11 +03:00 committed by GitHub
parent 4d91973220
commit 76bbdbf2f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/en/clean-copy/03-Section II. The Backwards Compatibility/07.md
View File

@ -22,7 +22,7 @@ Any software must be tested, and APIs ain't an exclusion. However, there are som
In the case of a gateway API that provides access to some underlying API or aggregates several APIs behind a single façade, there is a strong temptation to proxy the original interface as is, thus not introducing any changes to it and making a life much simpler by sparing an effort needed to implement the weak-coupled interaction between services. For example, while developing program execution interfaces as described in the [Chapter 9](#chapter-9) we might have taken the existing first-kind coffee-machine API as a role model and provided it in our API by just proxying the requests and responses as is. Doing so is highly undesirable because of several reasons:
* usually, you have no guarantees that the partner will maintain backwards compatibility or at least keep new versions more or less conceptually akin to the older ones;
* nay partner's problems will automatically ricochet into your customers.
* any partner's problem will automatically ricochet into your customers.
The best practice is quite the opposite: isolate the third-party API usage, e.g. develop an abstraction level that will allow for:
* keeping backwards compatibility intact because of extension capabilities incorporated in the API design;
@ -46,4 +46,4 @@ There are obvious local problems with this approach (like the inconsistency in f
Whatever tips and tricks that were described in the previous chapters you use, it's often quite probable that you can't do *anything* to prevent the API inconsistencies start piling up. It's possible to reduce the speed of this stockpiling, foresee some problems, and have some interface durability reserved for future use. But one can't foresee *everything*. At this stage, many developers tend to make some rash decisions, e.g. releasing a backwards-incompatible minor version to fix some design flaws.
We highly recommend never doing that. Remember that the API is a multiplier of your mistakes either. What we recommend is to keep a serenity notepad — to fix the lessons learned, and not to forget to apply this knowledge when the major API version is released.
We highly recommend never doing that. Remember that the API is a multiplier of your mistakes either. What we recommend is to keep a serenity notepad — to fix the lessons learned, and not to forget to apply this knowledge when the major API version is released.