Как протестировать api в браузере

Обновлено: 04.07.2024

В этом большом гайде мы разберем тестирование API с помощью Postman. Он покроет большинство сценариев использования этой программы в вашей повседневной работе.

Давным-давно Postman стартовал как расширение для Google Chrome. Сейчас это полноценное нативное приложение, доступное на Windows, Linux и MacOS.

Что такое API?

Что такое Postman?

Зачем использовать Postman?

Установка Postman

Установка подробно описана в отдельном гайде. Найти его можно здесь (! на английском)

После того, как Postman установлен, можно переходить к тестированию API.

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

Особенности Postman

Ниже мы перечислим только некоторые из особенностей Postman:

Простой в использовании API клиент
Функциональный и приятный UI.
Может использоваться как для ручного, так и для автоматизированного тестирования API.
Поддерживает интеграции с другими инструментами (например, поддерживает Swagger и RAML)
Может быть запущен в Windows, Linux, MacOS.
Не требует знания языков программирования.
Предоставляет возможность легко экспортировать коллекции запросов, наборы тестов. Можно легко обмениваться этими данными с коллегами.
Интегрируется с CI/CD инструментами (например, с Jenkins, TeamCity и т.п.)
API Posman-a подробно документирован.
Позволяет выполнять API автотесты.

Цена: Бесплатно или 21 доллар за пользователя в месяц.

Как пользоваться Postman

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

Основные сущности Postman: запросы, коллекции и окружения

Перед тем, как приступить непосредственно к тестированию, давайте рассмотрим основные сущности, которыми оперирует Postman:

1. Запросы (Requests)

Запрос представляет собой комбинацию URL, хедеров и Body (тела запроса). Postman позволяет сохранять запросы и использовать их в будущем там, где вам нужно.

Как мы писали выше, Postman позволяет делать запросы к API. С помощью API-запроса можно получать и отправлять данные какому-либо бэкенд-сервису.

GET: GET-запросы используются для получения данных от API.
POST: POST-запросы используются для отправки новых данных API.
PUT: PUT-запросы используются для обновления уже существующих данных.
PATCH: PATCH-запросы (как и PUT) используются для обновления уже существующих данных. Разница в том, что с помощью PATCH запросов можно обновить несколько записей за раз.
DELTE: DELETE-запросы используются для удаления существующих данных.

Далее в статье мы рассмотрим, как создавать и отправлять запросы разных типов с помощью Postman.

2. Коллекции (Collections)

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

Как создать коллекцию в Postman:

Введите имя (Name) и описание (Description) коллекции, после этого нажмите кнопку Create:

Коллекция может содержать любое число запросов. Запустить выполнение коллекции можно двумя способами:

с помощью Collection Runner
c помощью Newman

Далее мы рассмотрим оба этих способа.

3. Окружение (Environments)

Мы рассмотрим работу с окружениями далее в статье.

Тестирование GET-запросов

Повторимся, GET-запросы используются для получения данных с сервера. GET-запросы не меняют состояние данных на сервере (не добавляют, не удаляют и не изменяют данные).

Давайте отправим GET-запрос с помощью Postman:

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

Шаг 2: Создаем GET-запрос:

После выполнения запроса вы должны будете увидеть данные от сервера во вкладке Body.

На скриншоте ниже вы видите код ответа сервера (Status: 200 OK), время выполнения запроса (Time: 1700ms) и размер ответа (Size: 1.62 KB)

По наведению на Time и Size появляется всплывающее окно с подробной информацией.

Время ответа сервера (Response Time)

Размер ответа (Response Size)

Куки (Cookies): Здесь можно увидеть информацию о куках, возвращаемых сервером

Хедеры ответа от сервера (Response headers)

Тестирование POST-запросов

POST-запросы используются для отправки новых данных на сервер. Давайте попробуем с помощью POST-запроса добавить нового пользователя. Для этого мы отправим информацию о новом пользователе в теле POST-запроса.

После этого наживаем кнопку SEND и отправляем POST-запрос.

Примечание: для проверки корректности вашего json можно использовать Jsonformatter

Точно так же, как и POST, отправляются PUT, PATCH и DELETE запросы.

Примечание: во время тестирования, для каждого запроса проверяйте возвращаемый результат, код ответа сервера и время ответа сервера. И не забывайте про негативные тесты!

Параметризация запросов

Часто необходимо выполнить один и тот же запрос на разных наборах данных. С помощью параметризации, можно использовать переменные при выполнении запросов.

В Postman, параметры создаются с помощью двойных скобок: >.

Шаг 2: Меняем URL на параметр >. После этого URL запроса должен быть таким: >/users

Шаг 3: Теперь нам нужно создать переменную окружения, чтобы использовать ее в качестве параметра. Для этого нажимаем на кнопку с глазом и кликаем на Edit (редактировать), чтобы создать глобальную переменную и затем использовать ее в коллекциях.

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

Создание тестов в Postman

Тесты в Postman позволяют убедиться, что API работает так, как этого от него ожидают.

Давайте начнем с написания простого теста.

Код теста будет выглядеть следующим образом:

Запуск коллекций с помощью Collection Runner

Давайте запустим коллекцию с помощью Collection Runner.

Шаг 2: Должна будет открыться следующая страница:

Разберем основные элементы:

Шаг 3: В этом окне добавим коллекцию для запуска. Выбираем нашу коллекцию тестов, устанавливаем параметр Iterations в 2, delay в 2500ms и нажимаем кнопку запуска.

Запуск коллекций с помощью Newman

Для того, чтобы запустить коллекции с помощью Newman, делаем следующее:

Шаг 1: Устанавливаем node.js. Сделать это можно по ссылке

Шаг 2: Открываем командную строку и выполняем команду npm install -g newman

Шаг 3: После установки newman заходим в Postman. В списке коллекции находим нашу коллекцию, нажимаем на три точки и выбираем Export (Экспортировать)

Шаг 5: Выбираем папку, в которую экспортировать коллекцию и нажимаем Save. Рекомендуем создать отдельную папку для Postman-тестов. После нажатия на Save, коллекция будет экспортирована в выбранную папку.

Шаг 6: Для корректного запуска нам понадобится экспортировать и окружение. Для этого нажимаем на кнопку с глазом и выбираем опцию Download as JSON. Выбираем папку, в которую экспортировать окружение и нажимаем Save. Рекомендуем экспортировать окружение в ту же папку, в которую была экспортирована коллекция.

Шаг 7: Теперь, когда мы экспортировали коллекцию и окружения в папку, возвращаемся в командную строку и меняем директорию на ту, где находятся коллекция и окружение.

Шаг 8: Запускаем коллекцию с помощью команды:

newman run PostmanTestCollection.postman_collection.json -e Testing.postman_globals.json

После выполнения коллекции, появятся результаты выполнения тестов.

Заключение

В этом гайде по Postman мы постарались разобрать базовые темы. Мы надеемся, вы научились создавать и отправлять просты запросы, проверять ответы сервера, создавать простые тесты. Узнали, как выполнять коллекций с помощью Collection Runner и Newman. В следующих статьях мы разберем продвинутые возможности Postman.

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

Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.

Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).

Пирамида тестов

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

Тесты API проходят быстро, обеспечивают высокую рентабельность инвестиций и упрощают проверку бизнес-логики, безопасности, соответствия и других аспектов приложения. В случаях, когда API является общедоступным, предоставляя конечным пользователям программный доступ к нашему приложению или службам, тесты API фактически становятся сквозными тестами и должны охватывать всю пользовательскую историю(user story - прим.переводчика).

Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API - вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться - Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами - прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать.

Стратегия тестирования API

Стратегия тестирования - это высокоуровневое описание требований к тестированию, из которого впоследствии может быть составлен подробный план тестирования с указанием отдельных тестовых сценариев и тестовых случаев. Наша первая задача - это функциональное тестирование, чтобы убедиться, что API работает правильно.

Основными задачами функционального тестирования API являются:

убедиться, что реализация API работает правильно, как и ожидалось - без ошибок!

гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).

предотвратить регрессий между написанным кодом(merge) и релизом.

API как соглашение - сначала проверьте спецификацию!

API - это, по сути, соглашение между клиентом и сервером или между двумя приложениями. Перед тем, как начать любое тестирование функциональности, важно убедиться в правильности соглашения. Это можно сделать сначала проверив спецификацию (или само соглашение службы, например, интерфейс Swagger или ссылку OpenAPI) и убедившись, что:

эндпоинты правильно именованы;

ресурсы и их типы правильно отражают объектную модель;

нет отсутствующей или дублирующей функциональности;

отношения между ресурсами правильно отражаются в API.

Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).

Итак, какие аспекты API мы должны протестировать?

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

Этапы тестирования API

Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:

Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.

Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.

Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.

Категории тестовых сценариев

Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:

Основные позитивные тесты (прохождение успешного сценария по умолчанию)

Расширенное позитивное тестирование с дополнительными параметрами

Негативное тестирование с валидными входными данными

Негативное тестирование с недопустимыми входными данными

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

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

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

Деструктивное тестирование - это более глубокая форма негативного тестирования, когда мы намеренно пытаемся сломать API, чтобы проверить его надежность (например, отправляя заведомо большое тело запроса в попытке переполнить систему).

Тестовые потоки

Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:

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

Многоступенчатый рабочий поток с несколькими запросами - тестирование серии запросов, которые являются обычными действиями пользователя, поскольку одни запросы могут зависеть от других. Например, мы выполняем запрос POST, который создает ресурс и возвращает автоматически сгенерированный идентификатор в своем ответе. Затем мы используем этот идентификатор, чтобы проверить, присутствует ли этот ресурс в списке элементов, полученных запросом GET. Затем мы используем PATCH для обновления новых данных и снова вызываем запрос GET для проверки этого обновления. И в завершении, мы УДАЛЯЕМ этот ресурс и снова используем GET, чтобы убедиться, что записи больше нет.

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

Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.

Пример API и тестовая матрица

Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).

Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:

10 лучших инструментальных средств тестирования интерфейсов прикладного программирования 2018 года.

Интерес к тестированию неудержимо растёт на протяжении нескольких последних лет, согласно исследованиям Google Trends. Опрос, проведенный компанией Smartbear в 2017 году среди 5000 профессионалов в области разработки программного обеспечения, показал, что более 50% опрошенных респондентов используют автоматические средства тестирования API, и ожидается рост их количества на 30% ( с 59% до 77%) в течении следующих двух лет, причем 80% участников опроса указали, что отвечают за тестирование API.

Наличие правильных процессов, инструментов и технических решений для автоматических тестирований API становится важным, как никогда ранее. И с помощью тенденции shift-left, тестирование API становится больше, чем просто решение по контролю за качеством, теперь это критически важный компонент успешной непрерывной интеграции и развёртывания программного обеспечения.

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

5 лучших средств тестирования API в 2018 году

1. SoapUI

SoapUI представляет собой консольный инструмент, предназначенный для тестирования API и позволяющий пользователям легко тестировать API REST и SOAP, а также Web-сервисы.

При помощи SoapUI, пользователи могут получить полный исходный документ и встроить предпочтительный набор функций, в дополнение к перечисленным ниже:

Создать тест легко и быстро при помощи технологий перетаскивания объектов «мышкой» (Drag and drop) и метода «указания и щелчка» (Point-and-click)
Быстро создать пользовательский код при помощи Groovy
Мощное тестирование на основе данных: Данные загружаются из файлов, баз данных и Excel, поэтому они могут создать симуляцию взаимодействия пользователя и API.
Создание комплексных сценариев и поддержка асинхронного тестирования
Повторное использование скриптов: загрузка тестов и сканирование безопасности могут повторно использоваться в случае функционального тестирования всего в несколько шагов

2. Postman

Будучи изначально плагином браузера Chrome, теперь Postman расширяет свои технические решения вместе с оригинальными версиями как для Mac, так и для Windows.

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

Легкий в использовании клиент REST
Богатый интерфейс делает этот инструмент простым и удобным в использовании
Может использоваться как при автоматическом, так и при исследовательском тестировании
Работает в приложениях для Mac, Windows, Linux и Chrome
Обладает пакетом средств интеграции, таких как поддержка форматов Swagger и RAML
Обладает функциями Run, Test, Document и Monitoring
Не требует изучения нового языка программирования
Позволяет пользователям легко делиться опытом и знаниями с другими членами команды, поскольку позволяет упаковывать все запросы и ожидаемые ответы и отправлять их коллегам.

3. Katalon Studio

Katalon Studio является бесплатным инструментом автоматического тестирования, предоставляющим общую среду для создания и выполнения UI функционала, служб API/Web и тестирования мобильных платформ.

Способность комбинировать уровни UI и Business (службы API/Web) для различных операционных сред (Windows, Mac OS, Linux) расценивается как значительное преимущество Katalon Studio перед аналогичными продуктами.

Katalon Studio поддерживает запросы SOAP и RESTful с различными типами команд (GET, POST, PUT, DELETE) с параметризованными возможностями.
Основные свойства:

Поддержка теста комбинации между верификациями UI и API.
Поддержка тестирования запросов как SOAP, так и RESTful.
Сотни встроенных ключей для создания тестовых заданий.
Поддержка одной из самых мощных библиотеки проверки утверждений AssertJ для создания динамических утверждений в BDD-стиле.
Поддержка подхода, управляемого данными.
Может использоваться как при автоматическом, так и при исследовательском тестировании.
Отлично подходит как для профессионалов, так и для новичков

4. Tricentis Tosca

Tricentis Tosca представляет собой платформу непрерывного тестирования для Agile и DevOps. Среди преимуществ Tricentis Tosca следует отметить:

5. Apigee

Apigee является кросс-«облачным» средством тестирования API, позволяющим пользователям измерять и тестировать производительность API, обеспечивать техническую поддержку и разработку API при помощи других редакторов, таких как Swagger.

Данный инструмент является многошаговым и находится под управлением Javascript
Он позволяет разрабатывать, отслеживать, выполнять разворачивание и масштабирование API
Идентифицирует проблемы путем отслеживания трафика API, уровня ошибок и времени ответа
Легко создает прокси API из Open API Specification и выполняет их развертку в «облаке»
Модели разворачивания в «облаке», локального разворачивания и гибридного разворачивания работают на основе одного кода
PCI, HIPAA, SOC2, и PII для приложений и API
Apigee разработан специально для цифрового бизнеса и задач с интенсивной обработкой данных на под управлением мобильных платформ API и приложений, которые управляют ним.

6. JMeter

JMeter (открытое программное обеспечение) широко используется для функционального тестирования API, однако изначально он создавался для нагрузочного тестирования.

Поддерживает воспроизведение результатов тестирования
Автоматически работает с файлами CSV, позволяя команде быстро создавать уникальные значения параметров для тестирования API.
Благодаря интеграции между JMeter и Jenkins, пользователи могут включать тесты API в конвейерные обработки CI
Данный инструмент может использоваться как для статического, так и динамического тестирования производительности ресурсов

7. Rest-Assured

Rest-Assured является общедоступным предметно-ориентированным Java-языком, который делает службу тестирования REST более простой и удобной.

8. Assertible

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

9. Karate DSL

Karate DSL это новый инструмент для тестирования API, который помогает разрабатывать сценарии для BDD тестов на основе API простым способом, без написания характеристик этапов. Эти характеристики создаются самим KarateDSL, а поэтому пользователи могут запустить тестирование API легко и быстро.

Встроен на вершине Cucumber-JVM
Способен запускать тестирование и генерировать отчеты как любой другой стандартный проект Java
Тест может быть разработан без обязательного владения знаниями языка Java
Тесты могут легко создаваться даже непрограммистами
Поддерживает конфигурацию продвижения /переключения, а также многопотоковое параллельное выполнение кода

10. Ни одно решение не может совместить все инструменты
Это больно осознавать, однако, это правда!

Мы верим, что приведенный выше список представляет наилучшие решения, доступные на текущий момент, если Вы решили использовать автоматическое тестирование API. Однако, как и в случае с большинством продуктов в данной сфере, найти один инструмент, который совмещает все указанные функции, практически невозможно.

Некоторые могут посчитать, что свойств коммерческих продуктов (Postman, Tricentis Tosca,…) будет достаточно, однако цена вопроса будет служить серьезным сдерживающим фактором. Бесплатные и общедоступные решения (Rest-Assured, Karate DSL,…) являются довольно-таки приемлемыми, но требуют квалифицированных умений и много усилий для имплементации правильной платформы. Инструменты, которые удерживают баланс между ценой и другими факторами (Katalon Studio, Postman), могут иметь недостатки для некоторых типов проектов, и эти недостатки требуют пристальной оценки.

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

Настройка

Как всякий серьезный софт, curl требует установки в операционной системе. Хорошая новость: скорее всего, он уже установлен! Точнее, встроен в операционку. Уважающий себя тестировщик, разумеется, работает в Linux, а почти каждый дистрибутив Linux уже идет с curl. Более того, даже Windows 10 (начиная с версии 1803) поставляется с curl.

Проверим, есть ли в системе curl.

В Linux набираем в терминале:

Если все-таки работаешь в Windows, то запускаешь cmd или, лучше, PowerShell:

Команда покажет версию curl, прикрепленные библиотеки, дату релиза, поддерживаемые протоколы и поддерживаемые функции. В Linux увидим следующее:

Если введенная команда выдала ошибку, то curl не установлен, значит его надо скачать и поставить. Еще одна хорошая новость: он бесплатный (но есть нюансы, о которых в конце). Есть версии для практически всех операционных систем, размер ехе-шника не превышает 5 Мб.

Примечание. С этого момента, будут приводиться исключительно «линуксовые» bash-команды, для ясности и читабельности. Если ты сидишь в Windows и примеры почему-то не работают, попробуй добавлять «.exe» после команды curl, или удалять (возможные) лишние пробелы в строках (line breaks).

Базовые опции

Несмотря на то, что Curl очень простой инструмент, он имеет множество различных функций. Начнем с ними знакомиться:

--dump-header или -D : Сохраняет в указанный дамп-файл полученные заголовки. Пример: curl -D result.header .
--output или -O : Выводит в указанный дамп-файл, минуя stdout. Пример: curl -o result.json .

GET-метод

Мы познакомились с основами, пора перейти к более серьезным вещам.

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

Делаем первые запросы:

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

В файле result.headers видим, что запрос успешно выполнен, с кодом ответа 200 (все ОК), от сервера получен таймкод ответа (timestamp), и все заголовки.

В этом файле result.json находится тело ответа. Это данные, возвращенные сервером, в красивом JSON-формате (об особенностях формата читаем здесь).

POST-метод

Отправка простого текста

Как видим, в запрос включен кастомный заголовок "Custom-Header: Testing" . Он должен отображаться в теле ответа.

Смотрим теперь в файл result.headers

и файл result.json

Параметры строки запроса

В curl поддерживается не только простой текст, но и достаточно сложные параметры типа:

Сервер, как и предыдущем примере, правильно «зеркалит» параметры, которые curl отправил.

Отправка JSON-объекта

Тут мы добавили специальный заголовок Content-Type , сообщающий серверу, что ему посылается json-файл. Путь к файлу с данными указывается флагом -d с собачкой @ , и далее путь к файлу (в нашем случае это будет текущая папка).

Вот содержимое файла data.json , который надо создать:

И файл result.json :

И снова видим, как curl умеет корректно отправлять контент JSON-файлов на сервер.

Эмуляция отправки значений формы

Иногда может понадобиться имитировать отправку формы. Curl умеет и это:

Чтобы обозначить для сервера, что посылаются данные формы, добавляется заголовок с соответствующим MIME-типом (как показано выше), плюс параметр -F в каждом из полей и значений.

Видим, что сервер получил форму и правильно обработал все поля.

Отправка файла

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

Другие методы

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

Аутентификация

То есть код 401 (не прошла авторизация).

Добавим в запрос логин и пароль:

Все хорошо, авторизация прошла успешно.

Платный тариф

На скрине слева отрендеренный markdown-документ, справа полученные result.headers и result.json, и терминал внизу, куда тестировщику приходится глядеть чаще всего.

Вопреки убеждению, бытующему в определенных кругах, curl хорошо работает не только в REST-архитектуре, но и в SOAP.

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

Читайте также: