Понимание API

[seregaperm]

Прочитал книжку (или то, что сейчас представлено, если она еще не завершена). Интересно. Даже присоединился бы, но...

1. не указаны никакие отраслевые стандарты об API, которые существуют, как и где они применяются.

2. на мой взгляд, не совсем точно раскрыта суть API. Я бы дал немного другое объяснение. Ведь, даже из точного определения API - это программный интерфейс. Программный интерфейс, который предоставляет доступ к методам некоторой системы. Понимаете о чем я? Интерфейс и методы это не одно и то же. А вы начинаете разработку методов сквозь все главы, вместе с архитектурой приложения и логикой, обернутых в частный случай API (http). Зачем?

Требования программного интерфейса могут накладывать требования и ограничения на систему, к которой подключены, но не обязаны. Программный интерфейс и методы должны быть разделены в понятийной модели. В процессе проектирования, который вы предлагаете, должно быть указано, что вы это делаете осознанно и начали работу с другого конца. То есть все вроде бы по делу начинается, а потом все смешивается. Это как-то странно.

3. Может быть не заметил, но есть еще способ взаимодействия с API, когда вычисления не происходят в рамках текущего соединения: первый запрос клиента отправляет данные, сервер в ответ генерирует uuid запроса и сразу разрывает соединение. Скорость на уровне пинга. Потом клиент периодически спрашивает "готов ли ответ на запрос". Как-то так...

[twirl]

не указаны никакие отраслевые стандарты об API, которые существуют, как и где они применяются.

Это не совсем правда, в релевантных фрагментах стоят ссылки на стандарты, в частности, на semver, например.
Конкретным реализациям будут посвящены будущие разделы про HTTP API и SDK.

Зачем?

Книга посвящена скорее проектированию функциональности, которая выставляется наружу посредством какого-то интерфейса.
Главы про область применения, уровни абстракции — как раз про то, как понять что выставить. А главы про конечные объекты — про то, как.

Что касается http-подобных интерфейсов, то я делаю оговорку об этом в главе 6 — это просто наиболее удобный способ выразить мысль.

Это как-то странно.

Я не придумал иного способа показать ход мысли при дизайне API. Уровни абстракции — и так, простите за тавтологию, чрезмерно абстрактная концепция. Если её не иллюстрировать — главу будет невероятно сложно читать.

Может быть не заметил, но есть еще способ взаимодействия с API, когда вычисления не происходят в рамках текущего соединения: первый запрос клиента отправляет данные, сервер в ответ генерирует uuid запроса и сразу разрывает соединение. Скорость на уровне пинга. Потом клиент периодически спрашивает "готов ли ответ на запрос". Как-то так...

Это довольно частный вопрос. По сути — способ организации асинхронных запросов, и по-хорошему всё это взаимодействие должно просто абстрагироваться клиентом.