books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-01-29 18:04:15 +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

2
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;