books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-01-05 10:20:22 +02:00
Code Issues Releases Activity

SDK - the beginning

Browse Source
This commit is contained in:
Sergey Konstantinov 2023-02-24 23:01:36 +02:00
parent 10b3e53a7b
commit e0efb9b9fa
2 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/ru/drafts/05-Раздел IV. HTTP API и REST/07.md
View File

@ -58,6 +58,7 @@
##### Создание
Начнём с операции создания ресурса. Как мы помним из предыдущих глав, операция создания в любой сколько-нибудь ответственной предметной области обязана быть идемпотентной и, очень желательно, ещё и позволять управлять параллелизмом. В рамках парадигмы HTTP API идемпотентное создание можно организовать одним из трёх способов:
1. Через метод `POST` с передачей токена идемпотентности (им может выступать, в частности, ревизия ресурса):
```
POST /v1/orders/?user_id=<user_id> HTTP/1.1

15
src/ru/drafts/06-Раздел V. SDK и UI-библиотеки/01.md Normal file
View File

@ -0,0 +1,15 @@
### О содержании раздела
Аббревиатура «SDK» («Software Development Kit»), как и многие из обсуждавшихся ранее терминов, не имеет конкретного значения. Считается, что SDK отличается от API тем, что помимо программных интерфейсов содержит и какое-то количество готовых инструментов для работы с ними. Определение это, конечно, лукавое, поскольку почти любая технология сегодня идёт в комплекте со своим набором инструментов.
Тем не менее, у термина SDK есть и более узкое значение, в котором он часто используется: это клиентская библиотека, которая предоставляет нативный интерфейс для работы с некоторым клиент-серверным API. Чаще всего речь идёт о библиотеках для мобильных платформ или веб-платформы, которые работают поверх нижележащего HTTP API сервиса.
Среди подобных клиентских SDK особо выделяются те из них, которые предоставляют не только программные интерфейсы для работы с API, но также и готовые визуальные компоненты, которые разработчик может использовать. Классический пример такого SDK — это библиотеки карточных сервисов; в силу исключительной сложности самостоятельной реализации движка работы с картами (особенно векторными) вендоры API карт предоставляют и готовые библиотеки для работы с географическими сущностями, которые часто включают в себя и визуальные компоненты общего назначения — кнопки, метки, контекстные меню — которые могут применяться и совершенно самостоятельно вне контекста API (SDK) как такового.
Настоящий раздел будет посвящён именно двум этим технологиям:
* нативные клиентские «обёртки» поверх клиент-серверных API;
* нативные клиентские библиотеки, предоставляющие не только «обёртки» над нижележащими API, но и визуальные компоненты, с которыми конечный пользователь может взаимодействовать напрямую.
Во избежание нагромождения подобных оборотов мы будем называть первый тип библиотеки просто «SDK», а второй — «UI-библиотеки».
**NB**: вообще говоря, UI-библиотека может и не включать в себя никакой обёртки над клиент-серверным API. Этот случай интересует нас гораздо меньше (по причинам, которые мы изложим в следующих главах). Тем не менее, многие паттерны дизайна SDK, которые мы опишем далее, применимы и к «чистым» библиотекам. Аналогично, SDK может предоставлять доступ не к клиент-серверном или вообще сетевому API, а к какой-то нижележащей платформе; соображения, которые мы опишем в следующей главе, к таким SDK также применимы.