1
0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-08-10 21:51:42 +02:00

style fix

This commit is contained in:
Sergey Konstantinov
2023-02-28 17:18:14 +02:00
committed by GitHub
parent e28e0662df
commit 5a5e5ac1c4

View File

@@ -1,13 +1,13 @@
### On the Structure of This Book
The book you're holding in your hands comprises this Introduction and two sections: ‘The API Design’ and ‘The Backwards Compatibility’.
The book you're holding in your hands comprises this Introduction and three sections: ‘The API Design,’ ‘The Backwards Compatibility,’ and ‘The API Product.
In Section I, we will discuss designing APIs as a concept: how to build the architecture properly, from high-level planning down to final interfaces.
Section II is dedicated to an API lifecycle: how interfaces evolve over time, and how to elaborate the product to match users' needs.
Section II is dedicated to an API lifecycle: how interfaces evolve over time, and how to develop the product to match users' needs.
One more section is planned for the future: the ‘API as a Product’ section will be more about the un-engineering sides of the API, like API marketing, organizing customer support, and working with a community.
Finally, Section III is more about the un-engineering sides of the API, like API marketing, organizing customer support, working with a community, etc.
First, two sections are interesting to engineers mostly, while the third section is more relevant to both engineers and product managers. However, we insist that the third section is the most important for the API software developer. Since an API is a product for engineers, you cannot simply pronounce a non-engineering team responsible for product planning and support. Nobody but you understands more about your API's product features.
First two sections are interesting to engineers mostly, while the third section is more relevant to both engineers and product managers. However, we insist that the third section is the most important one for the API software developer. Since an API is a product for engineers, you cannot simply pronounce a non-engineering team responsible for product planning and support. Nobody but you knows better your API's product features.
Let's start.