Из каких основных компонентов состоит структура API?

А, слушай, ну вот эта вся ваша API-хуита, она же на самом деле не такая страшная, как её рисуют! Это ж просто договорённость, как две программы друг с другом трепаться будут, чтобы не получилось как в том анекдоте: один кричит «Муму!», а второй в ответ «Чё?». Вот чтобы такого не было, есть чёткие правила, блядь.

Смотри, представь, что API — это как меню в ресторане, только для программ. И в этом меню всё разложено по полочкам:

1. Эндпоинты (Endpoints) — это, сука, сами блюда в меню. То есть конкретные адреса, куда стучаться. Хочешь пользователей — /users, хочешь заказы — /orders/{id}. Всё просто, как три копейки.

2. Методы HTTP — это то, что ты с этим блюдом хочешь сделать. Пришёл, сел, листаешь меню — это GET (посмотреть). Нашёл, что хочешь, и крикнул официанту — это POST (создать заказ). Передумал, сказал «ой, лучше без лука» — это PUT или PATCH (обновить). А если всё, наелся, уходишь — это DELETE (удалить, отменить). Всё логично, ёпта!

3. Заголовки (Headers) — это твои особые пожелания официанту, шепчешь ему на ушко. Типа «Принеси мне это в JSON-контейнере» (Content-Type: application/json) или «Вот мой пропуск в VIP-зону» (Authorization: Bearer <token>). Без этих штук тебя либо не поймут, либо вообще выпрут на мороз, пидарас шерстяной.

4. Параметры — ну тут, блядь, вообще разнообразие. Это как уточнять детали заказа.

   • Query-параметры: Ты говоришь: «Принеси мне пользователей, но только активных!» — и в адресе появляется /users?active=true. После знака вопроса, всё видно.
   • Path-параметры: А это когда ты прямо в адрес вставляешь номер: «Мне нужен конкретно пользователь номер 42» — /users/42. Сервер смотрит и такой: «А, ну этого-то я знаю».
   • Параметры тела (Body): А это когда ты пишешь официанту целое сочинение на салфетке — что именно создать или изменить.

5. Тело запроса (Request Body) — вот та самая салфетка с подробностями. Используется, когда ты что-то создаёшь (POST) или меняешь (PUT/PATCH). Пишешь там обычно на JSON, реже на XML. Главное — почерк разборчивый, а то сервер обосрётся и вернёт ошибку.

6. Коды состояния HTTP (Status Codes) — а это, сука, самое важное! Ответ от кухни. Официант приносит тебе бумажку с цифрой.

   • 2xx — Всё охуенно! Заказ приняли, готовят, несут. 200 — «Держи, заказывал». 201 — «Создали твой заказ с нуля, молодец».
   • 4xx — Ты, мудак, что-то напутал. 400 — «Бро, ты в заявке какую-то хуйню написал, мы не поняли». 404 — «Такого блюда у нас нет, иди нахуй». Это твои косяки.
   • 5xx — А вот это уже пиздец на кухне. 500 — «У нас плита сломалась, шеф в истерике, извини». Тут уже не ты виноват, но есть всё равно не дадут.

7. Тело ответа (Response Body) — ну и наконец, само блюдо! Данные, которые тебе принесли. Обычно тоже в JSON. Если запрос был удачный — там будет то, что просил. Если нет — описание, что пошло не так.

Вот смотри, как это выглядит вживую, когда одна программа стучится к другой:

GET /api/v1/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Перевод на человеческий: «Эй, example.com! Дай-ка мне (GET) данные пользователя под номером 42. Пришли мне их, пожалуйста, в формате JSON (Accept). И, кстати, вот мой пропускной токен, я свой (Authorization)».

И если всё хорошо, в ответ придёт что-то вроде: 200 OK и тело с JSON, где будет имя, почта и прочая хуйня этого пользователя. А если токен просроченный — получишь 401 Unauthorized и пойдёшь, блядь, авторизовываться заново. Вот и вся магия, никакой ебалы мозговой!