03 postman rest api

В этом файле — пошаговые примеры работы с REST API через Postman. Мы будем использовать бесплатный учебный API JSONPlaceholder: он не требует регистрации и ключей, поддерживает все основные HTTP-методы и возвращает данные в JSON. После выполнения заданий вы сможете уверенно проверять любые REST API через Postman.

В предыдущем файле (REST и GraphQL) мы разобрали, как устроены REST и JSON. Здесь применяем это на практике.

---

О сервисе JSONPlaceholder

• Базовый URL: https://jsonplaceholder.typicode.com

• Документация: https://jsonplaceholder.typicode.com/

• Авторизация не требуется.

• Доступны ресурсы: posts (посты), comments (комментарии), users (пользователи), albums, photos, todos.

• API поддерживает GET, POST, PUT, PATCH, DELETE. Данные при POST/PUT/PATCH не сохраняются на сервере навсегда — сервис имитирует ответ, что удобно для обучения.

---

1. Установка Postman и первый запрос

Установка

1. Скачайте Postman: https://www.postman.com/downloads/.

2. Установите и запустите. Можно работать без регистрации (кнопка «Skip sign in»), но аккаунт позволит синхронизировать коллекции между устройствами.

Интерфейс

• Левая панель — коллекции (папки с запросами), история, окружения.

• Центр — вкладки запросов: метод (GET, POST…), URL, заголовки, тело.

• Правая часть — ответ: статус, время, заголовки, тело (Pretty, Raw, Preview).

Первый запрос: GET списка постов

1

Создайте новый запрос (кнопка + или File → New → HTTP Request), выберите метод GET и введите URL:

https://jsonplaceholder.typicode.com/posts

Нажмите Send.

2

В ответе вы увидите массив из 100 постов в JSON. Обратите внимание:

• Status: 200 OK — запрос выполнен успешно.

• Body — список объектов с полями userId, id, title, body.

Так вы выполнили первый REST-запрос через Postman.

3

Откройте Postman Console (View → Show Postman Console или Cmd/Ctrl + Alt + C). В консоли после отправки запроса можно увидеть:

• Request — метод, полный URL (с подставленными переменными), заголовки, тело запроса.

• Response — код ответа, заголовки ответа, тело ответа, время.

4

Практика: снова отправьте GET на https://jsonplaceholder.typicode.com/posts. В консоли разверните этот запрос и посмотрите блоки Request (URL, Headers) и Response (Status, Headers, Body). Затем добавьте в запрос заголовок X-Test: hello, отправьте ещё раз и убедитесь, что в Request → Headers он присутствует.

---

2. GET: получение данных

Получить один пост по ID

• Метод: GET

• URL: https://jsonplaceholder.typicode.com/posts/1

В ответе — один объект поста с id: 1. Подставьте в URL другие числа (1–100), чтобы получить разные посты.

Получить комментарии к посту

• Метод: GET

• URL: https://jsonplaceholder.typicode.com/posts/1/comments

В ответе — массив комментариев к посту с id = 1.

Пагинация: посты по страницам

JSONPlaceholder поддерживает пагинацию через query-параметры _page и _limit (см. введение — раздел про пагинацию).

• Метод: GET

• URL: https://jsonplaceholder.typicode.com/posts?_page=1&_limit=10

В ответе — только первые 10 постов. Для второй страницы: ?_page=2&_limit=10, для третьей — _page=3 и т.д. В заголовках ответа может быть Link со ссылками на следующую/предыдущую страницу.

Практика: выполните запрос с _page=1&_limit=5, затем с _page=2&_limit=5. Сравните список постов в ответах (разные id). При необходимости используйте переменные окружения: {{baseUrl}}/posts?_page={{page}}&_limit={{limit}}.

Получить пользователей

• Метод: GET

• URL: https://jsonplaceholder.typicode.com/users

Список из 10 пользователей с полями id, name, username, email, address, phone, website, company.

Получить одного пользователя

• Метод: GET

• URL: https://jsonplaceholder.typicode.com/users/1

Один объект пользователя. ID от 1 до 10.

Практика: выполните GET для /users, затем GET для /users/3. Сравните структуру ответа.

---

3. POST: создание ресурса

POST используется, когда мы «создаём» новый ресурс на сервере. В Postman нужно указать метод, URL, заголовок Content-Type и тело запроса в JSON.

Создать новый пост

1

Метод: POST URL: https://jsonplaceholder.typicode.com/posts

2

Во вкладке Headers добавьте (если ещё нет):

• Key: Content-Type

• Value: application/json

3

Во вкладке Body выберите raw и тип JSON, введите:

{
  "title": "Заголовок поста",
  "body": "Текст поста от студента",
  "userId": 1
}

4

Нажмите Send. В ответе будет Status: 201 Created и объект с полями title, body, userId и сгенерированным id (например, 101). Сервис не сохраняет данные навсегда, но форма ответа соответствует реальным API.

Создать задачу (todo)

• Метод: POST

• URL: https://jsonplaceholder.typicode.com/todos

• Body (raw, JSON):

{
  "title": "Изучить REST API",
  "completed": false,
  "userId": 1
}

Ожидайте 201 Created и объект с полем id.

Практика: отправьте POST на /posts с своими title и body. Проверьте, что в ответе приходит корректный JSON и код 201.

---

4. PUT и PATCH: изменение данных

Для обновления ресурса по URL используют PUT (полная замена) или PATCH (частичное обновление). В JSONPlaceholder оба метода работают по одному и тому же URL с указанием ID.

PUT — полное обновление поста

1

Метод: PUT URL: https://jsonplaceholder.typicode.com/posts/1

2

Body (raw, JSON):

{
  "id": 1,
  "title": "Обновлённый заголовок",
  "body": "Обновлённый текст поста",
  "userId": 1
}

3

В ответе — 200 OK и тот же объект. Сервис имитирует обновление.

PATCH — частичное обновление

Можно отправить только те поля, которые хотите изменить:

• Метод: PATCH

• URL: https://jsonplaceholder.typicode.com/posts/1

• Body (raw, JSON):

{
  "title": "Только заголовок изменён"
}

Ответ снова 200 OK с объектом поста (сервис может вернуть полный объект).

Практика: выполните PATCH для /posts/5, изменив только поле body. Убедитесь, что статус 200 и в ответе есть обновлённые данные.

---

5. DELETE: удаление

Метод DELETE запрашивает удаление ресурса по URL.

• Метод: DELETE

• URL: https://jsonplaceholder.typicode.com/posts/1

• Body не нужен.

В ответе — 200 OK (или 204 No Content). JSONPlaceholder не удаляет данные по-настоящему, но так в реальных API обычно подтверждают удаление.

Практика: отправьте DELETE на /posts/10. Проверьте код ответа. После этого выполните GET /posts/10 — сервис всё ещё вернёт пост, так как это учебный API.

---

6. Типы тела запроса (Body): JSON, Form Data и др.

Вкладка Body в Postman определяет, в каком формате отправляются данные на сервер. От выбранного типа зависят заголовок Content-Type и то, как вы вводите данные. Ниже — какие варианты есть и когда их использовать.

Варианты Body в Postman

Тип	Назначение	Content-Type (как правило)
none	Тела нет (GET, DELETE и т.д.)	—
form-data	Пары ключ–значение и загрузка файлов (multipart)	multipart/form-data
x-www-form-urlencoded	Классическая форма: ключи и значения в одной строке	application/x-www-form-urlencoded
raw	Произвольный текст: JSON, XML, HTML и т.д.	Зависит от выбора в выпадающем списке справа
binary	Файл целиком (изображение, PDF и т.д.)	По типу файла или задаётся вручную
GraphQL	Запрос/мутация GraphQL	application/json

JSON (raw + JSON)

Как в разделе про POST: выберите Body → raw → в выпадающем списке справа выберите JSON. Postman сам подставит заголовок Content-Type: application/json. В поле ввода пишете валидный JSON:

{
  "title": "Заголовок",
  "body": "Текст",
  "userId": 1
}

Используйте для большинства REST API, которые принимают и отдают JSON.

Form Data (form-data)

Нужен, когда API ожидает multipart/form-data: обычные поля плюс загрузка файлов (аватар, документ и т.д.).

1. Body → выберите form-data.

2. В таблице два столбца: Key и Value. Для каждого поля укажите ключ и значение.

3. Справа от ключа можно переключить тип с Text на File — тогда в Value выбираете файл с диска (появится кнопка «Select Files»).

Пример:

Key	Value	Тип
title	Мой пост	Text
body	Текст поста	Text
avatar	(выбор файла)	File

Postman сам сформирует тело в формате multipart/form-data и поставит заголовок Content-Type: multipart/form-data; boundary=.... Вручную ничего не дописывайте.

Когда использовать: формы с файлами, загрузка изображений/документов через API.

x-www-form-urlencoded

Классический формат HTML-форм: пары «ключ=значение», объединённые символом &, специальные символы в значениях кодируются (например, пробел как + или %20).

1. Body → выберите x-www-form-urlencoded.

2. Заполните таблицу Key и Value — Postman сам соберёт строку и подставит Content-Type: application/x-www-form-urlencoded.

Пример пар: login=ivan&password=secret&remember=1. В Postman вы просто вводите ключи и значения по строкам.

Когда использовать: API, которые принимают форму «как в браузере» без файлов; старые или простые endpoint’ы.

Raw с другими типами (XML, Text, HTML)

Если нужно отправить не JSON, а, например, XML или обычный текст:

1. Body → raw.

2. В выпадающем списке справа выберите XML, Text, HTML или JavaScript (для тела запроса это по сути текст; тип влияет на подсветку и на то, ставит ли Postman Content-Type автоматически).

3. Введите содержимое в поле.

Для XML Postman обычно подставляет Content-Type: application/xml. Если ваш API ждёт другой заголовок (например, text/xml), добавьте его вручную во вкладке Headers.

Binary

Когда тело запроса — один файл целиком (не форма с полями, а именно файл в теле).

1. Body → binary.

2. Нажмите Select File и выберите файл. Он будет отправлен как есть в теле запроса.

3. При необходимости задайте нужный Content-Type во вкладке Headers (например, image/png, application/pdf).

Когда использовать: загрузка файла «как есть» в API (не через form-data).

Как задать Content-Type вручную

Если выбранный тип Body не подставляет нужный заголовок или API требует точный формат:

1. Откройте вкладку Headers.

2. Добавьте заголовок Key: Content-Type, Value: например application/json или application/xml; charset=utf-8.

Значение в Headers перекрывает то, что Postman ставит автоматически по типу Body.

Кратко: что выбрать

• JSON для REST API → Body: raw, тип JSON.

• Форма с файлами → form-data, поля и при необходимости File.

• Форма без файлов (как в браузере) → x-www-form-urlencoded.

• XML или свой текст → raw + выбор XML/Text/HTML и при необходимости свой Content-Type в Headers.

• Один файл в теле → binary + выбор файла.

---

7. Работа с заголовками (Headers)

Заголовки (Headers) — это пары «имя — значение», которые отправляются вместе с запросом (и приходят в ответе). В них передаётся тип тела запроса, авторизация, язык, кэширование и другие метаданные. В Postman заголовки запроса настраиваются во вкладке Headers.

Где и как задавать заголовки

1. Откройте запрос и перейдите на вкладку Headers.

2. В таблице два столбца: Key и Value. Для каждого заголовка укажите имя и значение.

3. Слева от строки можно включить или выключить галочку — отключённый заголовок не отправляется.

4. Переменные подставляются и здесь: в Value можно писать {{token}}, {{baseUrl}} и т.д.

Часть заголовков Postman добавляет сам (например, при выборе Body → raw → JSON подставится Content-Type: application/json). Заголовки, заданные вручную во вкладке Headers, имеют приоритет и могут перекрыть автоматические.

Часто используемые заголовки запроса

Заголовок	Назначение	Пример значения
Content-Type	Формат тела запроса	application/json, application/x-www-form-urlencoded, multipart/form-data
Accept	Какие форматы ответа принимает клиент	application/json, */*
Authorization	Авторизация (токен, Basic и т.д.)	Bearer {{token}}, Basic base64(login:password)
Accept-Language	Предпочитаемый язык ответа	ru, en-US
X-Request-ID, X-Correlation-ID	Идентификатор запроса для логов и трассировки	UUID или любая строка
User-Agent	Идентификация клиента (браузер, приложение)	PostmanRuntime/7.x (Postman подставляет сам), можно переопределить
Cookie	Куки для сессии (если API использует)	session=abc123

Для большинства REST API достаточно Content-Type (часто выставляется по типу Body) и Authorization при защищённых endpoint’ах.

Authorization через заголовок

Если вы не используете вкладку Authorization (тип OAuth 2.0 или Bearer Token), а храните токен в переменной окружения, заголовок можно задать вручную:

• Key: Authorization

• Value: Bearer {{token}}

Тогда при каждом запросе подставится значение переменной token из активного окружения.

Content-Type и Body

Тип тела (JSON, form-data и т.д.) часто определяет нужный Content-Type. Postman при выборе raw → JSON сам добавляет Content-Type: application/json. Если API требует точное значение (например, с кодировкой или подтипом), добавьте заголовок вручную во вкладке Headers:

• application/json; charset=utf-8

• application/xml

• text/plain

Заголовок, заданный в Headers, перекрывает тот, что Postman подставил по типу Body.

Просмотр заголовков ответа

После отправки запроса во вкладке Response есть блок Headers — там видны все заголовки ответа сервера: Content-Type, Set-Cookie, кастомные заголовки API и т.д. Это полезно при отладке (проверить, что сервер вернул нужный тип данных или токен в заголовке).

Куки (Cookie)

Если API использует куки (например, сессию после логина), сервер в ответе присылает заголовок Set-Cookie, а клиент при следующих запросах должен отправлять заголовок Cookie с сохранёнными значениями.

Как отправить куки вручную: во вкладке Headers добавьте строку с ключом Cookie и значением в формате имя1=значение1; имя2=значение2 (например, session_id=abc123). Можно использовать переменную: session_id={{sessionId}}.

Как Postman сам подставляет куки: Postman может запоминать куки из ответов (из заголовка Set-Cookie) и при следующих запросах к тому же домену автоматически добавлять заголовок Cookie. Это настраивается: Settings (шестерёнка) → Cookies — включить/выключить управление куками. Список сохранённых кук по доменам можно посмотреть через Cookies (ссылку под полем URL или в меню). Там же можно вручную добавить, изменить или удалить куку для домена.

Практика: если у вас есть API с логином по кукам, выполните запрос логина, в Response → Headers найдите Set-Cookie, скопируйте значение (или посмотрите куки в Cookies). В следующем запросе либо убедитесь, что куки включены в настройках и Postman подставит их сам, либо добавьте заголовок Cookie вручную с тем же значением.

Кастомные заголовки (X-, Api-Key и т.д.)

Многие API требуют свой заголовок: например, X-API-Key: ваш_ключ или X-Tenant-ID: 123. Добавляете новую строку в Headers, в Key пишете имя заголовка, в Value — значение или переменную {{apiKey}}. Имена заголовков регистронезависимы по стандарту HTTP, но на практике их пишут так, как указано в документации API.

Практика: в любом запросе добавьте заголовок Accept-Language: ru, отправьте запрос и во вкладке Response → Headers посмотрите, какие заголовки вернул сервер. Затем добавьте заголовок X-Custom-Header: test и убедитесь, что он уходит в запросе (можно проверить во вкладке Console — Postman показывает отправленные заголовки).

---

8. Переменные и окружение

Чтобы не копировать одни и те же значения в каждый запрос (базовый URL, токен, ID пользователя) и легко переключаться между разными средами (учебный API, тестовый и боевой API компании), в Postman используют переменные и окружения (Environments).

Что такое окружение и переменные

• Окружение (Environment) — это набор переменных с именами и значениями.

• Переменная — пара «имя → значение». В запросах вы подставляете значение по имени, а само значение храните в одном месте.

• В каждый момент времени активно одно выбранное окружение. Какое окружение активно — видно в выпадающем списке справа вверху в Postman.

Так вы сможете иметь одну и ту же коллекцию запросов и переключаться между «Учебный API», «Тест» и «Прод» только сменой окружения, без правки каждого запроса.

Какие бывают переменные (scope)

В Postman переменные живут в разных областях видимости (scope). От этого зависит, где их задавать, кто их видит и что перекрывает что при подстановке.

Тип переменных	Где задаются	Зачем нужны	Как использовать в запросах
Environment (окружение)	Environments → выбранное окружение	Разные значения для разных сред: тест/прод, свой токен, свой baseUrl.	{{baseUrl}}, {{token}}
Collection (коллекция)	Коллекция → вкладка Variables	Общие для всей коллекции значения, не зависящие от окружения: например, версия API.	{{apiVersion}}
Global (глобальные)	Иконка шестерёнки → Globals	Значения на весь Postman: один токен или URL для всех коллекций.	{{globalToken}}
Local (локальные)	Только в скриптах: pm.variables.set("x", 1)	Временные переменные на время выполнения одного запроса.	pm.variables.get("temp")
Data (из файла)	При запуске коллекции (Collection Runner) — выбор CSV/JSON файла	Массовый прогон: в каждой итерации подставляются разные значения из файла.	{{login}}, {{password}} в итерациях Runner'а

Приоритет подстановки: Local → Environment → Collection → Global.

Создание окружения и переменных

1. В левой панели нажмите Environments (или иконка шестерёнки).

2. Create Environment — введите название, например: JSONPlaceholder.

3. В таблице добавьте переменные: имя (например baseUrl), Initial Value и Current Value.

4. Нажмите Save.

Пример переменных для учебного API:

Variable	Initial Value / Current Value
baseUrl	https://jsonplaceholder.typicode.com
userId	1

Как использовать переменные в запросах

Синтаксис: {{имя_переменной}}.

• URL: {{baseUrl}}/posts

• URL с ID: {{baseUrl}}/users/{{userId}}

• Header: Authorization: Bearer {{token}}

• Body: "userId": {{userId}} или "token": "{{token}}"

Важно: выберите нужное окружение в выпадающем списке справа вверху.

Initial Value и Current Value

• Initial Value — шаблонное значение, сохраняется и удобно для совместного использования.

• Current Value — реально подставляемое значение (часто содержит секреты) и используется при подстановке. Если задан только Initial, Postman использует его.

Несколько окружений

Создайте, например, два окружения:

1. JSONPlaceholder — baseUrl = https://jsonplaceholder.typicode.com.

2. API компании (тест) — baseUrl = https://api-test.company.com, token = ....

В коллекции везде используйте {{baseUrl}} и при необходимости {{token}}. Переключая окружение, вы меняете среду для всех запросов.

---

9. Коллекции и повторное использование

Коллекция — это папка с набором запросов. Удобно хранить все примеры для одного API в одной коллекции.

Создать коллекцию

1. В левой панели: Collections → + (Create collection).

2. Назовите, например: JSONPlaceholder — учебные запросы.

Добавить запросы в коллекцию

• Перетащите вкладку запроса в коллекцию или

• В коллекции нажмите Add request и настройте метод, URL и body.

Можно создать папки внутри коллекции, например: GET, POST, PUT/PATCH, DELETE, и раскладывать запросы по ним.

Сохранить примеры из этого файла

Рекомендуется завести в коллекции минимум такие запросы:

Имя запроса	Метод	URL / переменная
Список постов	GET	{{baseUrl}}/posts
Один пост	GET	{{baseUrl}}/posts/1
Создать пост	POST	{{baseUrl}}/posts + JSON body
Обновить пост	PUT	{{baseUrl}}/posts/1 + JSON body
Удалить пост	DELETE	{{baseUrl}}/posts/1

Потом эту же коллекцию можно скопировать и заменить baseUrl на адрес API вашей компании — структура запросов останется понятной.

---

10. Скрипты: Pre-request и Tests (JavaScript)

В Postman можно выполнять JavaScript до отправки запроса (Pre-request Script) и после получения ответа (Tests). Так вы автоматизируете подготовку данных, проверку ответов и сохранение значений в переменные для следующих запросов.

Зачем нужны скрипты

• Pre-request Script выполняется до отправки запроса — подставить время, случайный ID, заголовок с токеном и т.д.

• Tests выполняется после получения ответа — проверка кода и тела, сохранение полей (например, id или access_token) в переменные окружения.

Скрипты можно задать на уровне запроса или коллекции.

Среда выполнения: JavaScript и API Postman

Доступны JavaScript и объект pm:

• pm.environment.get("name"), pm.environment.set("name", value)

• pm.collectionVariables.get("name"), pm.collectionVariables.set("name", value)

• pm.variables.get("name")

• pm.request — данные текущего запроса (в Pre-request можно менять запрос)

• pm.response — только в Tests: pm.response.code, pm.response.json(), pm.response.text()

• pm.sendRequest() — асинхронный запрос из скрипта

Для тестов часто используют pm.test("описание", function() { ... }) и pm.response.to.have.status(200).

Pre-request Script: примеры

Пример — записать текущий Unix timestamp:

pm.environment.set("timestamp", Math.floor(Date.now() / 1000));

Случайный ID:

pm.environment.set("randomId", Math.floor(Math.random() * 10000));

Подставить токен в заголовок:

var token = pm.environment.get("token");
if (token) {
    pm.request.headers.upsert({ key: "Authorization", value: "Bearer " + token });
}

Tests (post-response): примеры

Проверить код ответа:

pm.test("Status code is 200 or 201", function () {
    var code = pm.response.code;
    pm.expect(code).to.be.oneOf([200, 201]);
});

Сохранить id из ответа POST:

pm.test("Status is 201 Created", function () {
    pm.response.to.have.status(201);
});

pm.test("Response has id", function () {
    var json = pm.response.json();
    pm.expect(json).to.have.property("id");
    pm.environment.set("lastPostId", json.id);
});

Сохранить токен из ответа логина:

pm.test("Login successful", function () {
    pm.response.to.have.status(200);
});

var json = pm.response.json();
if (json.access_token) {
    pm.environment.set("token", json.access_token);
}

Практические задания

1

Pre-request: В запросе «Создать пост» добавьте в Pre-request Script установку переменной timestamp (как в примере выше). В Body в поле title используйте строку вида Тест {{timestamp}}. Отправьте запрос несколько раз и убедитесь, что заголовки постов различаются.

2

Tests: В запросе «Создать пост» добавьте в Tests проверку статуса 201 и сохранение id ответа в переменную lastPostId. Создайте запрос «Получить созданный пост» с URL {{baseUrl}}/posts/{{lastPostId}}. Сначала выполните «Создать пост», затем «Получить созданный пост» — во втором запросе должен подставиться ID из первого ответа.

3

Цепочка: В коллекции настройте порядок: запрос 1 — логин (если у вас есть такой API), в Tests сохраните токен в token; запрос 2 — любой защищённый endpoint с Pre-request, который подставляет Authorization: Bearer {{token}}. Запустите коллекцию (Run) и убедитесь, что второй запрос идёт с токеном из первого.

После выполнения вы сможете использовать скрипты для автоматической подстановки токенов, проверки ответов и связки запросов в сценариях (логин → запрос с токеном, создание → запрос по ID).

---

11. Что дальше

Вы научились:

• отправлять GET, POST, PUT, PATCH, DELETE в Postman;

• настраивать заголовки запроса (Headers) и выбирать тип тела (JSON, Form Data и др.);

• задавать Content-Type, Authorization и кастомные заголовки;

• читать статусы ответов и заголовки ответа;

• использовать переменные окружения и коллекции;

• писать Pre-request и Tests на JavaScript для автоматизации и проверок.

Дальше в методичке:

• OAuth 2.0 в Postman — получение токена и авторизованные запросы (следующий файл);

• работа с реальным API вашей компании (авторизация, конкретные endpoint’ы);

• выполнение тех же запросов через curl и из кода (на выбранном языке);

• разбор ошибок (4xx, 5xx) и лучших практик.

Рекомендуется сохранить коллекцию с примерами из этого файла, затем перейти к OAuth 2.0 в Postman.