Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 В спецификации HTTP есть много правил и рекомендаций, но их все равно недостаточно для построения полноценного API.

2 Есть множество вопросов, на которые спецификация HTTP не отвечает:

3 <ul><li>Как строить URL?</li>

4 <li>Как работать с ошибками?</li>

5 <li>В каком формате и какой структуры возвращать данные?</li>

6 <li>Как делать пагинацию?</li>

7 </ul>Именно поэтому для построения хорошего API недостаточно правил HTTP. Нужны дополнительные соглашения, которые мы изучим в этом уроке.

8 За время существования интернета было создано немало стандартов API. Среди них можно выделить несколько больших направлений, которые строятся по примерно одинаковым правилам.

9 Ниже мы рассмотрим их подробнее, а пока просто познакомимся с ними:

10 <h2>API по принципу "как придется"</h2>

11 Сюда попадают все API, которые делают по принципу "как получится". Обычно они встречаются во внутренних сервисах или публичных старых сервисах, созданных десятки лет назад.

12 Здесь нет никаких правил:

13 <ul><li>каждый эндпоинт существует сам по себе</li>

14 <li>активно используются параметры запроса</li>

15 <li>игнорируются коды ответа и другие возможности самого HTTP</li>

16 </ul>В теории такие API делать не стоит, но на практике они иногда встречаются.

17 <h2>Архитектурный стиль REST</h2>

18 REST - это архитектурный стиль, который был заложен в сам протокол HTTP, ведь его придумал один из создателей HTTP.

19 API, построенный по этому принципу, вовсю использует возможности HTTP. Такое API активно опирается на заголовки, коды ответов, грамотно созданные эндпоинты. Например,<a>Example Api</a>построен по принципам REST.

20 Можно сказать, что глобальная идея REST - использовать для проектирования API возможности, заложенные в HTTP изначально:

21 Однако REST не отвечает на те вопросы из начала урока. REST - это архитектурный стиль, а не конкретный стандарт. В эндпоинтах выше мы видим адреса и методы HTTP, но мы не знаем, какими будут данные в запросах и в ответах. Поэтому любое REST API имеет свои особенности, которые присущи только ему - у него есть свой способ обработки ошибок и своя структура возвращаемых данных.

22 Разработчики пытаются создать стандарт, который добавляет в REST все недостающие части. Самый удачный пример -<a>json</a>

23 . Этот стандарт описывает конкретные структуры данных для разных типов запросов и ответов. Так может выглядеть извлечение конкретного пользователя:

24 <h2>Удаленный вызов процедур (Remote Procedure Call, RPC)</h2>

25 RPC API появились в интернете практически раньше всех остальных видов API. Здесь HTTP рассматривается как способ доставки API, но сам по себе не является частью API.

26 Как правило, RPC API работают с одним эндпоинтом - например, /rpc, на который отправляется GET или POST. RPC API используют небольшое количество заголовков и кодов ответов. Обработка ошибок, выполнение разных действий - все это в RPC зашито в само тело запроса и ответа.

27 Идея RPC в том, что мы просто вызываем обычные функции, а они каким-то магическим образом делают запросы на внешнюю систему, полностью или почти полностью скрывая от нас существование HTTP и сети в целом.

28 Запрос в JSON-RPC выглядит как JSON, в котором указывается, какую функцию и с какими параметрами нужно вызвать:

29 В ответе приходит результат вызова этой функции:

30 Разновидностей RPC очень много, и они сильно отличаются между собой. Из наиболее известных можно назвать NFS, SOAP, XML-RPC, JSON-RPC, gRPC, GraphQL.