Перейти на PRO

Что такое endpoint в контексте API?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Endpoint (конечная точка) в API — это уникальный URL-адрес, по которому клиентское приложение может взаимодействовать с сервером для выполнения определенной операции над ресурсом.

Почему это ключевое понятие? Тестирование API в значительной степени сводится к проверке корректности работы его эндпоинтов.

Структура эндпоинта: [Метод HTTP] [Базовый URL]/[Путь к ресурсу]

Примеры REST API эндпоинтов для сущности "Пользователь":

# 1. Получить список всех пользователей
GET https://api.example.com/v1/users

# 2. Получить данные конкретного пользователя (с ID=123)
GET https://api.example.com/v1/users/123

# 3. Создать нового пользователя
POST https://api.example.com/v1/users
# Тело запроса (Body): {"name": "Alice", "email": "alice@example.com"}

# 4. Частично обновить данные пользователя 123
PATCH https://api.example.com/v1/users/123
# Body: {"email": "new.alice@example.com"}

# 5. Удалить пользователя 123
DELETE https://api.example.com/v1/users/123

Ключевые аспекты эндпоинта для тестирования:

  1. HTTP-метод: Определяет действие (GET, POST, PUT, PATCH, DELETE).
  2. Путь (Path): Идентифицирует ресурс или коллекцию (/users, /users/{id}).
  3. Параметры запроса:
    • Query Parameters: Фильтрация, сортировка, пагинация (?role=admin&page=2).
    • Path Parameters: Часть URL для идентификации ресурса (/users/{id}).
  4. Заголовки (Headers): Метаданные (авторизация Authorization: Bearer <token>, тип контента Content-Type: application/json).
  5. Тело запроса (Body): Данные для создания или обновления ресурса (обычно JSON).
  6. Ответ (Response): Код состояния HTTP (200 OK, 404 Not Found), тело ответа и заголовки.

Эндпоинты должны быть четко описаны в спецификации API (OpenAPI/Swagger).

Ответ 18+ 🔞

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

Эндпоинт — это, блядь, окошко, в которое ты стучишься и орешь своё «ДАЙ!».

Вот этот весь адрес — https://api.example.com/v1/users — это и есть окошко. А метод — это то, как ты орешь.

Почему это главное? Да потому что тестировать API — это как проверять, не обманывает ли тебя продавщица в этом ларьке. Кинул ей десять рублей — получил «Жигулёвское». Кинул пятак — получил по ебалу. Всё через это окошко!

Из чего эта хуйня собрана:

[Как орем] [Где ларек]/[На что орем]

Смотри, как это для «Пользователей» работает:

# 1. Орем "ДАЙ ВСЕХ!" (Это GET)
GET https://api.example.com/v1/users
# Ответ: получаем список всех алкашей, которые уже ходили к этому ларьку.

# 2. Орем "ДАЙ КОНКРЕТНОГО ПЕТЬКУ!" (Тоже GET, но с уточнением)
GET https://api.example.com/v1/users/123
# Ответ: получаем Петьку. Или получаем по ебалу, если Петьки нет (404, блядь).

# 3. Орем "ВОТ, ЗАПИШИ НОВОГО ЛОХА!" (Это POST, мы что-то отдаём)
POST https://api.example.com/v1/users
# А в теле запроса суём записку: {"name": "Васян", "email": "vasya@pivo.ru"}
# Ответ: ларек должен сказать "OK, записал" и выдать Васину новую ID-карту (айдишник).

# 4. Орем "ИСПРАВЬ В ВАСЬКИНОЙ АНКЕТЕ ПОЧТУ, ОН ОБОСРАЛСЯ!" (PATCH)
PATCH https://api.example.com/v1/users/123
# Тело: {"email": "vasya.ny@budesh.zvat.ru"}
# Ответ: "Исправил, пошёл нахуй".

# 5. Орем "УДАЛИ ЭТОГО МУДАКА ВАСЬКУ ИЗ БАЗЫ!" (DELETE)
DELETE https://api.example.com/v1/users/123
# Ответ: "Васька больше не клиент. Всё, свободен".

На что смотреть, когда тестируешь эту бандуру:

  1. Метод (Как орем). Перепутал GET с DELETE — и вместо списка пользователей удалил всю базу. Пиздец и увольнение.
  2. Путь (На что орем). Криво написал /usres вместо /users — получишь в ответ 404 Not Found, будто ларёк закрыли на обед, епта.
  3. Параметры (Уточняем запрос).
    • Query (?): «Дай пользователей, но только админов (?role=admin) и со второй страницы (&page=2)». Как фильтр в интернет-магазине, блядь.
    • Path (/{id}): Циферка прямо в адресе. Как номер квартиры.
  4. Заголовки (Наши документики). Без правильного заголовка Authorization: Bearer tokentokentoken тебя примут за бомжа и выгонят с очереди. А заголовок Content-Type: application/json — это как сказать: «Мужик, я тебе не голосом объяснять буду, а запиской на бумажке (в JSON)».
  5. Тело запроса (Сама записка). Тут всё, что мы хотим создать или поменять. Главное — JSON правильный написать, а то опять получишь 400 Bad Request, будто ты каракулями неразборчивыми написал.
  6. Ответ (Что нам выдали).
    • Код статуса: 200 — ок, получил. 201 — ок, создал. 400 — сам дурак, запрос кривой. 401 — кто ты такой? 404 — нет такого. 500 — у них на сервере всё упало, иди нахуй.
    • Тело ответа: Собственно, данные или сообщение об ошибке.
    • Их заголовки: Могут быть полезные штуки, типа X-Total-Count (сколько всего записей).

И вся эта, блядь, архитектура должна быть прописана в документации (типа OpenAPI), а не в голове у того пидораса, который это API писал. Иначе тестирование превращается в гадание на кофейной гуще, ёпта.

© ХакСобесов, 2026
support@hacksobesov.com