Preparing the release

README.md

@@ -6,7 +6,7 @@ This is the working repository for ‘The API’ book written by Sergey Konstant
 API-first development is one of the hottest technical topics nowadays since many companies started to realize that API serves as a multiplicator to their opportunities—but it also amplifies the design mistakes as well.
 
 This book is written to share the expertise and describe the best practices in designing and developing APIs. It comprises six sections dedicated to:
-  * the API design
+  * The API design
   * API patterns
   * backwards compatibility
   * HTTP API & REST
@@ -17,13 +17,11 @@ This is an open-source book distributed under the [Creative Commons Attribution-
 
 ## Current State and the Roadmap
 
-Right now three sections (‘The API Design’, ‘The Backwards Compatibility’, and ‘The API Product’) are finished, comprising the [first edition of the book](/docs/v1/). Three other sections are drafted and are now being added to the clean copy chapter after chapter.
+The second edition of the book is finished! This is everything I ever wanted to tell the reader.
 
-Also, the book still lacks readable schemes which I'm still planning to plot with mermaid.
-
-## Translation
-
-I am translating new chapters into English at the moment they're ready. I'm not a native speaker, so feel free to correct my grammar.
+There are several areas to improve:
+  * Add more diagrams
+  * Add more live code examples (specifically — `SearchBox` designed in MVP paradigm and using React/Redux).
 
 ## Contributing
 
@@ -31,6 +29,8 @@ I am accepting inquiries. Feel free to open issues.
 
 I am NOT accepting pull requests introducing any new content, since I'm willing to be the only author. I would gratefully accept typo fixes, though.
 
+## Acknowledgments
+
 Thanks [art.mari.ka](https://www.instagram.com/art.mari.ka/) for the illustration & inspiration.
 
 Thanks [Ilya Subbotin](https://ru.linkedin.com/in/isubbotin) and [Fedor Golubev](https://www.linkedin.com/in/fedor-golubev-93910b5/) for the valuable feedback.

src/en/clean-copy/05-Section IV. HTTP APIs & the REST Architectural Principles/02.md

@@ -79,7 +79,7 @@ Let's be honest: HTTP APIs do suffer from the listed problems. However, we can c
   2. If necessary, API designers can customize the list of returned fields in HTTP APIs. It aligns well with both the letter and the spirit of the standard. However, as we already explained to the reader in the “[Partial Updates](#api-patterns-partial-updates)” chapter, trying to minimize traffic by returning only subsets of data is rarely justified in well-designed APIs.
 
   3. If standard JSON deserializers are used, the overhead compared to binary standards might indeed be significant. However, if this overhead is a real problem, it makes sense to consider alternative JSON serializers such as *simdjson*[ref simdjson : Parsing gigabytes of JSON per second](https://github.com/simdjson/simdjson). Due to their low-level and highly optimized code, *simdjson* demonstrates impressive throughput which would be suitable for all APIs except some corner cases.
-      * The combination of gzip/brotli + simdjson largely renders the use of optimized JSON derivatives, such as BSON, unnecessary in client-server communication.[ref BSON](https://bsonspec.org/)
+      * The combination of gzip/brotli + simdjson largely renders the use of optimized JSON derivatives, such as BSON,[ref BSON](https://bsonspec.org/) unnecessary in client-server communication.
 
   4. Generally speaking, the HTTP API paradigm implies that binary data (such as images or video files) is served through separate endpoints. Returning binary data in JSON is only necessary when a separate request for the data is a problem from the performance perspective. These situations are virtually non-existent in server-to-server interactions and/or if HTTP/2 or a higher protocol version is used.
 

src/en/clean-copy/05-Section IV. HTTP APIs & the REST Architectural Principles/05.md

@@ -63,7 +63,7 @@ It is quite obvious that in this setup, we put excessive load on the authorizati
       GET /v1/orders?user_id=<user id>
       ```
 
-[![PLOT](/img/graphs/http-api-organizing-02.en.png "Step 2. Adding explicit user identifiers")]()
+[![PLOT](/img/graphs/http-api-organizing-02.en.png "Step 1. Adding explicit user identifiers")]()
 
 **NB**: We used the `/v1/orders?user_id` notation and not, let's say, `/v1/users/{user_id}/orders`, because of two reasons:
   * The orders service stores orders, not users, and it would be logical to reflect this fact in URLs

src/en/l10n.json

@@ -62,8 +62,8 @@
         "githubHref": "https://github.com/twirl/The-API-Book",
         "githubString": "github.com/twirl/The-API-Book",
         "twitterHref": "https://twitter.com/blogovodoved",
-        "kindleHref": "https://www.amazon.com/gp/product/B09RHH44S5/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i0",
-        "kindleTag": "buy Kindle version [1st edition]",
+        "kindleHref": "https://www.amazon.com/gp/product/B09RHH44S5/",
+        "kindleTag": "buy Kindle version",
         "mediumHref": "https://twirl.medium.com/",
         "mediumTag": "Medium",
         "substackHref": "https://twirl.substack.com/",

src/ru/l10n.json

@@ -62,8 +62,8 @@
         "githubHref": "https://github.com/twirl/The-API-Book",
         "githubString": "github.com/twirl/The-API-Book",
         "twitterHref": "https://twitter.com/blogovodoved",
-        "kindleHref": "https://www.amazon.com/gp/product/B09RHH44S5/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i0",
-        "kindleTag": "buy Kindle version [1st edition]",
+        "kindleHref": "https://www.amazon.com/gp/product/B09RHH44S5/",
+        "kindleTag": "buy Kindle version",
         "mediumHref": "https://twirl.medium.com/",
         "mediumTag": "Medium",
         "habrHref": "https://habr.com/ru/users/forgotten/",