Задать вопрос

Введение в REST API и знакомство с Postman

Рассказываем, что представляет собой REST API, как устроены HTTP-запросы, в каком формате сервер возвращает данные и как с помощью Postman выполнить отправку запроса, получить ответ и проверить корректность работы сервера.
В современных IT-системах взаимодействие между компонентами почти всегда строится через API. Клиентские приложения не обращаются к базе данных напрямую и не выполняют бизнес-логику самостоятельно. Все операции проходят через сервер, который принимает запрос, обрабатывает его и возвращает результат.

Такой подход позволяет централизовать правила работы с данными, контролировать доступ и упрощать развитие системы.

Один из наиболее распространенных подходов к построению интерфейсов взаимодействия — REST. Про него мы писали в прошлой статье.

Он применяется при разработке веб-сервисов, мобильных приложений и внутренних корпоративных систем. Для проверки и тестирования таких интерфейсов используется Postman — программный инструмент, позволяющий выполнять HTTP-запросы к серверу и анализировать полученные ответы.

Что такое REST и почему о нем говорят в контексте API

REST (Representational State Transfer) — это архитектурный подход, который определяет правила взаимодействия между клиентской и серверной частью системы.

Он не определяет формат данных и не привязывает реализацию к конкретному языку, а задает набор ограничений, которые делают систему предсказуемой и масштабируемой.

Одним из ключевых принципов REST является разделение ролей клиента и сервера. Клиент отвечает за формирование запроса, сервер — за обработку логики и работу с данными. Это позволяет изменять клиентскую часть без вмешательства в серверную реализацию.

Еще одно важное ограничение — отсутствие сохранения состояния (stateless). Каждый HTTP-вызов включает всю информацию, которая требуется для полноценной обработки запроса. Благодаря этому сервер может обслуживать множество клиентов без хранения сессионных данных, а отказ одного запроса не влияет на другие.

REST также предполагает использование единого интерфейса. Клиент всегда обращается к ресурсам одинаковым образом, независимо от их внутренней реализации.

Это упрощает работу с API и снижает количество ошибок при интеграции.
Если собрать основные требования REST в один список (по этим требованиям вас могут спросить на собеседовании!), получится так:
  • Client-Server
    Разделение ролей клиента и сервера.
  • Stateless
    Отсутствие состояния на стороне сервера между запросами.
  • Cache
    Возможность кэширования ответов.
  • Uniform Interface
    Единый, предсказуемый интерфейс взаимодействия.
  • Layered System
    Разделение системы на уровни.
  • Code on Demand
    Опциональная передача исполняемого кода на сторону клиента.
На практике термин REST API обычно применяется для обозначения HTTP-интерфейса, который:
  • Работает поверх протокола HTTP
  • Использует набор типовых HTTP-операций для обращения к ресурсам
  • Возвращает структурированные данные (чаще всего в JSON)
  • Опирается на требования REST, включая единообразие интерфейса и stateless-подход
Именно эти принципы делают REST API популярным выбором для современных веб- и мобильных приложений, где важны скорость разработки, стабильность и простота интеграции.

В результате взаимодействие получается предсказуемым: клиент формирует запрос, сервер возвращает статус и данные, а типовые ошибки легко читаются по коду ответа.

Как устроено приложение и какую роль в нем играет API

Большинство современных программных приложений строится по трехуровневой архитектуре. Такой подход используется как в веб-разработке, так и в корпоративных IT-системах, поскольку позволяет разделить ответственность между компонентами и упростить развитие продукта.
  • Верхний уровень
    Клиентский слой (user interface), с которым работает пользователь: веб-сайт, мобильное приложение или другая клиентская программа.

    Клиент отвечает за отображение информации и формирование запроса, но не содержит бизнес-логики и не работает с базой данных напрямую.
  • Средний уровень
    Сервер приложений. Именно здесь сосредоточена основная логика системы: обработка входящих http запросов, проверка прав доступа, выполнение операций и подготовка ответа.

    Сервер принимает запрос от клиента, анализирует его параметры и решает, какие действия необходимо выполнить
  • Нижний уровень
    Хранилище данных. Это база данных или другое постоянное хранилище, доступ к которому осуществляется только через сервер.

    Клиент не взаимодействует с этим уровнем напрямую, что снижает риски ошибок и повышает безопасность.
API здесь играет роль «входной двери» в сервер: клиент обращается к набору методов, а сервер решает, что сделать с данными и какой ответ вернуть. В свою очередь клиентское приложение не знает, как именно устроена серверная часть и где хранятся данные.
API (application programming interface) — это описание того, каким образом одна программа может обмениваться данными с другой. API определяет набор доступных операций, формат входных параметров, структуру ответа и возможные ошибки.

Такой интерфейс позволяет разным клиентам использовать одну и ту же серверную логику без дублирования кода.
Когда этот интерфейс реализован в соответствии с принципами REST и использует HTTP как транспорт, его называют REST API. При таком подходе клиент формирует и отправляет запрос на сервер, сервер выполняет обработку и возвращает результат в стандартизированном формате. Как правило, данные передаются в виде JSON, что упрощает их автоматическую обработку.

Использование REST API дает возможность подключать к серверу разные типы клиентов (сайт, мобильное приложение или внутренние сервисы), сохраняя единые правила работы с данными и бизнес-логикой системы.

Из чего состоит HTTP-запрос и как применяются методы REST

Обмен данными с API выполняется с помощью HTTP-запросов. Каждый запрос включает три логические части:
GET /api/users?page=2 HTTP/1.1
Host: reqres.in
Стартовая строка
Содержит метод, URL ресурса и версию протокола. Так, метод GET применяется для получения данных, а POST — для их передачи на сервер. В URL могут указываться параметры запроса в формате «ключ=значение».
GET https://reqres.in/api/users?page=2&per_page=3 HTTP/1.1
Заголовки запроса
Описывают контекст вызова. Они передаются как пары «ключ: значение» и используются для указания формата данных, типа клиента и других параметров. Например, заголовок Content-Type сообщает серверу, в каком виде передан request body — то есть содержимое запроса.
Accept: application/json
Accept-Language: ru-RU,ru;q=0.9
Content-Type: application/json
Authorization: Bearer <token>
Тело запроса
применяется тогда, когда необходимо передать данные на сервер. Такой подход используется в методах POST, PUT и PATCH. Метод DELETE служит для удаления ресурса, а GET тела запроса не содержит.
POST https://reqres.in/api/users HTTP/1.1
Content-Type: application/json

{
  "name": "Ivan",
  "job": "QA"
}
Удобно помнить это как правило: строка «что сделать», заголовки «в каком контексте», тело «какие данные передать».

Важно различать назначение методов. GET применяется для чтения данных, POST — для создания ресурса, PUT — для полной замены, PATCH — для частичного обновления, DELETE — для удаления. Такая схема часто описывается как Post Put Delete цикл работы с ресурсом.
Хочешь стать системным аналитиком?
Учись с нами!
Начать учиться

Формат JSON и структура ответа

В большинстве REST-сервисов обмен данными происходит в формате JSON. Это текстовый формат, удобный для чтения и обработки. Он применяется как для отправки данных на сервер, так и для получения ответа.

JSON использует объекты и массивы, внутри которых данные представлены в виде пар «ключ–значение». Значениями могут быть строки, числа, логические значения или null, поэтому формат хорошо подходит для передачи структурированных данных между системами.
{
  "page": 2,
  "per_page": 3,
  "data": [
    { "id": 7, "email": "michael.lawson@reqres.in" },
    { "id": 8, "email": "lindsay.ferguson@reqres.in" },
    { "id": 9, "email": "tobias.funke@reqres.in" }
  ]
}
Ответ сервера всегда содержит код ответа (status code), который отражает итог обработки. К примеру, код 200 означает успешное выполнение, коды 4xx указывают на ошибку запроса, а 500 (internal server error) сигнализирует о проблеме на стороне сервера.
HTTP/1.1 200 OK
Date: Fri, 20 Sep 2019 08:17:58 GMT
Server: cloudflare
Content-Type: application/json

Postman как инструмент для тестирования API

Для ручного тестирования REST API часто применяют Postman. Этот инструмент позволяет формировать запросы, анализировать ответы и сохранять историю работы. Postman есть под разные операционные системы и подходит как для разработчиков, так и для специалистов по тестированию и обеспечению качества ПО (software testing).
Postman позволяет создавать запросы, группировать их в коллекции, использовать переменные и документировать API. Такой подход удобен как для индивидуальной работы, так и для командного использования.
Для создания запроса используется пункт «New», после чего выбирается тип «HTTP Request». Далее указывается метод, URL, заголовки и тело запроса при необходимости.
Если запрос не уходит или возвращается неожиданный результат, сначала проверьте мелочи: корректность URL (включая случайный пробел в конце строки), выбранный метод и заголовок Content-Type. В Postman это видно сразу, поэтому инструмент удобен для первичной проверки API до подключения клиента.
После заполнения параметров выполняется отправка запроса. Для этого используется кнопка «Send» (send button). После отправки Postman покажет код ответа (например, 200), содержимое ответа в формате JSON/XML и служебные заголовки.
pm.test("Status code is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Response has data array", function () {
  const jsonData = pm.response.json();
  pm.expect(jsonData.data).to.be.an("array");
});

Авторизация, коллекции и расширенные возможности

Во многих API требуется авторизация. Она настраивается во вкладке «Authorization» и определяет, какие действия разрешены клиенту. Postman позволяет задать авторизацию один раз и применить ее ко всей коллекции.
Для удобства Postman поддерживает коллекции (collection) — логические группы запросов. Коллекции позволяют хранить связанные запросы, повторно использовать настройки и упрощают тестирование сложных сценариев.

Внутри коллекции можно применять переменные окружения (environment) и глобальные переменные, что упрощает работу с разными серверами и учетными данными.

Дополнительно Postman предоставляет возможность документирования API. С помощью функции «View in web» формируется страница на сайт, где отображаются методы, параметры и примеры запросов. Это удобно для передачи информации другим участникам проекта и получения обратной связи.
Таким образом, Postman — универсальный инструмент для работы с API. С его помощью можно отправить запрос, получить ответ, проверить код состояния и убедиться, что сервер корректно обрабатывает данные.

По мере роста задач Postman можно применять для более сложных сценариев: писать тесты на JavaScript, автоматизировать проверки (automated testing) и внедрять их в CI/CD-процессы (continuous integration). Такой подход делает работу с REST-сервисами предсказуемой и управляемой.

Хочешь стать системным аналитиком? Учись с нами!

Начать учиться