Что такое эндпоинт в api
Шаг 2 «Конечные точки и методы (Описание API)»
Конечные точки указывают, как получить доступ к ресурсу, а метод указывает разрешенные взаимодействия (такие как GET, POST или DELETE) с ресурсом.
Один и тот же ресурс обычно имеет множество связанных конечных точек, каждая из которых имеет разные пути и методы, но возвращает различную информацию об одном и том же ресурсе. Конечные точки обычно имеют краткие описания, похожие на общее описание ресурса, только еще короче. Кроме того, конечная точка показывает только конечный путь URL ресурса, а не базовый, общий для всех конечных точек, путь.
Примеры конечных точек
Вот пример конечной точки ресурса User API Instagram
Конечная точка обычно выделяется стилизованным образом для придания ей более визуального внимания. Большая часть документации строится вокруг конечной точки, поэтому, может, имеет смысл визуально выделить конечную точку в нашей документации.
Конечная точка, возможно, является наиболее важным аспектом документации API, потому что она является тем, что разработчики будут реализовывать для выполнения своих запросов.
Представление параметра path при помощи фигурных скобок
Параметры path в конечных точках, представляют в фигурных скобках. Например, вот пример из API Mailchimp:
По возможности, параметр path выделяют другим цветом:
Фигурные скобки для параметров path являются условием, понятным пользователям. В приведенном выше примере почти ни одна конечная точка не использует фигурные скобки в синтаксисе фактического пути, поэтому
Вот пример из API Facebook, где параметр path выделен цветом для его легкой идентификации:
Для выделения параметров, при их описании в документации Facebook, используется зеленый цвет, который помогает пользователям понять их значение.
Параметры path не всегда выделяются уникальным цветом (например, некоторым может предшествовать двоеточие), но, как бы то ни было, нужно убедиться, что параметр path легко идентифицируется.
Перечисляем методы конечной точки
Для конечной точки обычно перечисляют методы (GET, POST и т. Д.). Метод определяет работу с ресурсом. Вкратце, каждый метод выглядит следующим образом:
См. Request methods в статье Wikipedia по HTTP для получения дополнительной информации. (Существуют дополнительные методы, но они редко используются.)
Поскольку о самом методе особо говорить нечего, имеет смысл сгруппировать метод с конечной точкой. Вот пример из Box API:
А вот пример API LinkedIn:
Конечная точка показывает только конечный путь
Когда мы описываем конечную точку, мы указываем только конечный путь (отсюда и термин «конечная точка»). Полный путь, который содержит как базовый путь, так и конечную точку, часто называют URL-адресом ресурса.
Как сгруппировать несколько конечных точек одного ресурса
Еще стоит обращать внимание при документировании конечных точек и методов, как группировать и перечислять конечные точки, особенно если у нас много конечных точек для одного и того же ресурса. В Примерах описания ресурсов мы рассмотрели различные API. Многие сайты документации используют различные схемы группировки или перечисления каждой конечной точки ресурса, поэтому не будем возвращаться к тем же примерам. Группируйте конечные точки таким образом, осмысленно, например, по методу или по типу возвращаемой информации.
Если конечные точки в основном совпадают, объединение их на одной странице может иметь смысл. Но если они в значительной степени уникальны (с разными ответами, параметрами и сообщениями об ошибках), разделение их на разные страницы, вероятно, лучше (и проще в управлении). Опять же, создав более сложный дизайн сайта, мы можем сделать большую информацию доступной для навигации на той же странице.
Как ссылаться к конечным точкам в инструкциях
Как ссылаться к конечным точкам в разделе API в руководствах и другом безадресном контенте? Ссылка на конечную точку /aqi или на конечную точку /weatherdata не имеет большого значения. Но для более сложных API-интерфейсов использование конечной точки для описания ресурса может оказаться непростым делом.
В одной компании URL-адреса конечных точек ресурса Rewards выглядели так:
А Rewards в контексте Missions выглядели вот так:
Сказать, что можно использовать ресурс Rewards, не всегда было достаточно конкретно, потому что было несколько Rewards и конечных точек Missions.
Чем длиннее конечная точка, тем более громоздкой становится ссылка. Эти виды описаний будут чаще встречаться в концептуальных разделах вашей документации. Как правило, нет четкого правила, как ссылаться на громоздкие конечные точки. Смысловой подход нашего API определим самостоятельно.
Конечная точка API surfReport
Давайте создадим описание «Конечные точки и методы» для нашего вымышленного API Surfrefport. Вот пример:
Следующие шаги
Теперь, когда мы описали ресурс и перечислили конечные точки и методы, пришло время заняться одной из самых важных частей API: раздел “Параметры”.
REST API на Java без фреймворков
Перевод статьи подготовлен специально для студентов курса «Разработчик Java».
В экосистеме Java есть много фреймворков и библиотек. Хотя и не так много, как в JavaScript, но они и не устаревают так быстро. Тем не менее, это заставило меня задуматься о том, что мы уже забыли, как писать приложения без фреймворков.
Вы можете сказать, что Spring — это стандарт и зачем изобретать велосипед? А Spark — это хороший удобный REST-фреймворк. Или Light-rest-4jis. И я скажу, что вы, конечно, правы.
Но вместе с фреймворком, помимо готовой функциональности, вы получаете много магии, сложности с изучением, дополнительные функции, которые вы, скорее всего, не будете использовать, а также баги. И чем больше стороннего кода в вашем сервисе, тем больше вероятность того, что у вас будут ошибки.
Сообщество open source очень активное, и есть большая вероятность, что ошибки в фреймворке будут быстро исправлены. Но все же, я хотел бы призвать вас подумать, действительно ли вам нужен фреймворк. Если у вас небольшой сервис или консольное приложение, возможно, вы сможете обойтись без него.
Что вы можете получить (или потерять), используя чистый Java-код? Подумайте об этом:
Когда я начал писать этот код, то часто сталкивался с ситуациями, когда отсутствовал функционал, который есть в Spring из коробки. В эти моменты, вместо того, чтобы взять Spring, надо было переосмыслить и разработать все самостоятельно.
Я понял, что для решения реальных бизнес-задач я, все же, предпочел бы использовать Spring, а не изобретать велосипед. Тем не менее, я считаю, что это упражнение было довольно интересным опытом.
Начинаем
Я буду описывать каждый шаг, но не всегда буду приводить полный исходный код. Полный код вы можете посмотреть в отдельных ветках git-репозитория.
и Jackson для JSON-сериализации
Для упрощения POJO-классов будем использовать Lombok:
и vavr для средств функционального программирования
Исходный код в ветке step-1.
Первый эндпоинт
Веб-сервер запускается на порту 8000 и предоставляет эндпоинт, который просто возвращает Hello. Это можно проверить, например, используя curl:
Исходный код в ветке step-2.
Поддержка разных HTTP-методов
Наш первый эндпоинт работает отлично, но вы можете заметить, что независимо от того, какой HTTP-метод использовать, он всегда отвечает одинаково.
Первое, что нужно сделать, это добавить код для различения методов, например:
Попробуйте еще раз такой запрос:
ответ будет примерно таким:
Исходный код в ветке step-3.
Парсинг параметров запроса
Парсинг параметров запроса — это еще одна «функция», которую нам нужно реализовать самостоятельно.
Мы могли бы распарсить параметры следующим образом:
и использовать, как показано ниже:
Полный пример в ветке step-4.
Аналогично, если мы хотим использовать параметры в path. Например:
Чтобы получить элемент по нам нужно распарсить url самостоятельно. Это становится громоздким.
Безопасность
Часто нам нужно защитить доступ к некоторым эндпоинтам. Например, это можно сделать, используя базовую аутентификацию (basic authentication).
Для каждого HttpContext мы можем установить аутентификатор, как показано ниже:
Значение “myrealm” в конструкторе BasicAuthenticator — это имя realm. Realm — это виртуальное имя, которое может быть использовано для разделения областей аутентификации.
Подробнее об этом можно прочитать в RFC 1945.
Теперь вы можете вызвать этот защищенный эндпоинт, добавив заголовок Authorization :
Для аутентификации в реальном приложении вы, вероятно, получите учетные данные из заголовка и сравните их с именем пользователя и паролем, хранящимися в базе данных.
Если вы не укажете заголовок, то API ответит статусом
Полный пример в ветке step-5.
JSON, обработка исключений и прочее
Теперь пришло время для более сложного примера.
Из моего опыта в разработке программного обеспечения наиболее распространенным API, который я разрабатывал, был обмен JSON.
Мы собираемся разработать API для регистрации новых пользователей. Для их хранения будем использовать базу данных в памяти.
У нас будет простой доменный объект User :
Я использую Lombok, чтобы избавится от бойлерплейта (конструкторы, геттеры).
В REST API я хочу передать только логин и пароль, поэтому я создал отдельный объект:
Объекты User создаются в сервисе, который будем использовать в обработчике API. Сервисный метод просто сохраняет пользователя.
В реальном приложении можно сделать больше. Например, отправлять события после успешной регистрации пользователя.
Реализация репозитория выглядит следующим образом:
Наконец, склеим все вместе в handle() :
Здесь JSON-запрос преобразуется в объект RegistrationRequest :
Также мне нужно преобразовать объект RegistrationResponse обратно в JSON-строку. Для этого используем Jackson
( com.fasterxml.jackson.databind.ObjectMapper ).
Вот как я создаю новый обработчик ( handler ) в main() :
Рабочий пример можно найти в ветке step-6. Там я также добавил глобальный обработчик исключений для отправки стандартных JSON-сообщений об ошибках. Например, если HTTP-метод не поддерживается или запрос к API сформирован неправильно.
Вы можете запустить приложение и попробовать один из следующих запросов:
Endpoint – What is an API Endpoint?
Application Program Interface (API) permits the interaction between two systems. And with almost every institution adopting the API strategy, it’s critical that you understand the various aspects and fundamentals of API and how to manage them so that you can deliver the highest level of user experience. One crucial thing that you need to understand is what an API endpoint is and why it is essential.
What Is An API Endpoint?
In simple terms, an API endpoint is the point of entry in a communication channel when two systems are interacting. It refers to touchpoints of the communication between an API and a server. The endpoint can be viewed as the means from which the API can access the resources they need from a server to perform their task. An API endpoint is basically a fancy word for a URL of a server or service.
We all know that APIs operate through ‘requests’ and ‘responses.’ And when an API requests to access data from a web application or server, a response is always sent back. The location where the API sends a request and where the response emanates is what is known as an endpoint. Reputedly, the endpoint is the most crucial part of the API documentation since it’s what the developer will implement to make their requests.
API vs Endpoint
An API refers to a set of protocols and tools that allow interaction between two different applications. In simple terms, it is a technique that enables third-party vendors to write programs that can easily interface with each other. On the other hand, an endpoint is the place of interaction between applications. API refers to the whole set of protocols that allows communication between two systems while an endpoint is a URL that enables the API to gain access to resources on a server.
Why Are API Endpoints Important?
As more individuals are starting to appreciate the use of APIs to aid in the transfer of critical data, transactions, and processes, it has become vitally imperative to understand the various aspects that makeup API. As such, making sure that the communication touchpoints between systems are robust is crucial to API success. Endpoints help to depict the exact location of the resources to be accessed by API and also play a vital role in ensuring that the software which is interacting with the API is functioning correctly. Therefore, the performance and productivity of APIs depend on its ability to interact and communicate with endpoints effectively.
How Are API Endpoints Secured?
In this age of digital economy when massive loads of data are being piped through APIs, whether it is in science, education, gaming or business, it is surprising that nothing much is being said about the security of data and information on APIs. However, this write-up highlights a few things that can be done to improve the safety of APIs. The first thing is to secure the API endpoints.
The begging question is: How do you secure API endpoints?
1. Utilize one-way password hashing
To guarantee the safety of API endpoints, it is recommended that you store your password using (“one-way”) or asymmetric encryption algorithms. Symmetric and plain-text storage of passwords should be avoided at all costs.
2. Make HTTPS your only option
APIs that allow users and applications to interact via HTTP and other non-secure protocols are highly prone to hackers. To avoid putting your clients in danger, it is crucial to make sure that HTTPs is the only available option regardless of how trivial the endpoint might seem.
3. Institute rate limiting
Enforcing a limit of how many requests a customer can make to the API helps to discourage bots and avoid unnecessary use of system resources.
4. Solid authentication
Although every API comes with a distinct form of authentication, there are a few authentication techniques that industry leaders perceive to be the best. For instance, the Oath2 system is preferred since it segregates accounts into various resources and permits limited access to the token bearer.
5. Input validation is crucial
Validating input helps to decipher and identify threats early enough before they reach the clients. Atop checking whether data in the right format, you should also look for other surprises such as SQL injection which might erase your database if left unchecked.
What Is The Best Way To Publish API Endpoints (On RapidAPI)?
The primary function of API endpoints is to provide a means of interaction between an API and a server. Each endpoint boasts a specified format both for its request and responses. And the best thing is that you don’t need any knowledge to use them. RapidAPI allows you to publish, launch and monetize your API on the world’s largest API marketplace. Using a simple UI, you can add your endpoints and parameters in minutes. As long as you use the right format, you will be able to utilize your API endpoints effectively.
How to Create your own API Endpoint?
To start, go to the Endpoints tab of your API Definition. Select the “+Create Endpoint” button.
The following page will then appear:
This page is where you can define all of the following functionality:
You can specify custom headers to be passed to your API endpoint by the user. To add a header, navigate to the Header tab on the Add Endpoint screen.
You can provide the following information for request headers:
Query String Parameters
Adding a Query String parameter can be used to add additional parameters to a request. For example, a filter (imagine “?limit” or “?offset”) could be an additional query string parameter passed with the request. To add a query string parameter, navigate to the Query tab on the Add Endpoint screen.
You can provide the following information for query string parameters:
Body Parameters (Only for POST, PUT and PATCH)
When you specify the method to query the endpoint as a POST, PUT, or PATCH method, you can also define a payload for the request. You can add it as a form parameter or as a model.
Payload Form Encoded Parameters
A payload defined as a form-encoded parameter is the simplest and recommended way to pass arguments into the payload.
Defining a payload to be posted to an endpoint in this way gives you a lot of flexibility, as you can specify many parameters & create nested objects.
For Enterprises
Bring software to market more rapidly with a dedicated API marketplace:
Check Out These APIs
Primary Sidebar
Build amazing apps, faster.
Discover, evaluate, and integrate with any API. RapidAPI is the world’s largest API Hub with over 2,000,000 developers and 20,000 APIs.
Create an Enterprise API Marketplace
Bring software to market more rapidly with a dedicated API marketplace:
Что такое эндпоинт в api
Документирование новой конечной точки
До этого момента мы выступали в роли разработчика с задачей интеграции данных о погоде на свой сайт. Цель состояла в том, чтобы понять, какая информация нужна разработчикам и как они используют API.
Теперь сменим роль. Теперь у нас роль технического писателя, работающего в команде OpenWeatherMap. Команда просит задокументировать новую конечную точку. Что будем писать, какой поход применим?
Нужно документировать новую конечную точку
Менеджер проекта вызывает и говорит, что у команды есть новая конечная точка, которую нужно документировать к следующему релизу. (Иногда команды называют каждую конечную точку «API».)
Большинство технических писателей не начинают с нуля документацию проекта. Инженеры обычно помещают важную информацию на внутреннюю вики (или передают информацию во время встреч). Однако информация на вики-странице, скорее всего, будет неполной и излишне технической в некоторых местах (например, описание схемы базы данных или высокоуровневых архитектурных рабочих процессов). Информация может также включать в себя только внутреннюю информацию (например, тестовые логины, протоколы доступа или кодовые имена) или содержать давно устаревшие разделы.
В конечном счете, информация будет ориентирована на других инженеров того же уровня знаний, что и инженеры команды. Работа технического писателя заключается в том, чтобы взять эту информацию и превратить ее в полную, точную, полезную информацию, которая сообщается аудитории.
wiki-страница с информацией о новой конечной точке
Теперь наша задача отсортировать информацию на той фиктивной вики-странице и создать из нее документацию. Можно прочитать макет вики-страницы ниже, чтобы получить представление об информации. В следующих разделах мы будем знакомиться с каждой секцией API.
Вот мок внутренней вики-страницы:
Wiki страница: «Surf Report API»
Конечной точкой является /surfreport/
Если добавить час, то в ответе будет состояние прогноза только за указанный час. В противном случае будет прогноз за 3 дня с условиями, перечисленными по часам для каждого дня.
Ответ будет включать в себя высоту прибоя, ветер, температуру, прилив и общую рекомендацию.
Пример конечной точки с параметрами:
Ответ содержит три элемента:
Рекомендация основана на алгоритме, который выбирает оптимальные условия серфинга, оценивает их по рубрике и включает один из трех ответов.
Отрицательные значения прилива означают поступающий прилив.
Отчет не будет содержать параметров разрывных течений.
Хотя пользователи могут вводить названия пляжей, в отчет включены только определенные пляжи. Пользователи могут посмотреть, какие пляжи доступны на нашем сайте по адресу http://example.com/surfreport/beaches_available. При передаче в конечной точке имена пляжей должны быть закодированы в виде строк запроса.
Вот пример того, как разработчики могут интегрировать информацию
Если запрос искажен, вы получите код ошибки 400 и указание на ошибку.
Как видно, информация в примере wiki-страницы не структурирована и ее трудно читать. Путем разделения информации API на пять стандартных разделов информация приобретет лучшую форму и станет более читабельной.
Давайте перейдем к Обзору пошагового описания API для изучения пяти шагов, которые мы рассмотрим при создании раздела адресного API для этой новой конечной точки.
Что такое эндпоинт в api
В этой статье я хочу поделиться опытом освоения тестирования (в т. ч. автоматизации) на уровне API (Application Programming Interface – интерфейс программирования приложений, интерфейс прикладного программирования). Надеюсь, что предлагаемый материал будет представлять интерес для всех, кто ранее проводил тестирование через графический интерфейс и еще не имеет опыта работы с http-запросами.
Немного о REST API и SOAP API
Стоит отметить, что на сегодняшний день есть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:
Если уподобить HTTP-запрос бумажному носителю, то можно сказать, что REST API в большинстве случаев передает простые записки, а время от времени – письмо в конверте (возможно, написав при этом часть послания и на самом конверте). В свою очередь, SOAP API передает все инструкции в подробном письме стандартного вида, используя конверт (единичный HTTP-запрос) лишь как средство доставки. Для лучшего понимания разницы подходов я рекомендую читателю посмотреть следующую инфографику.
В статье речь будет идти о REST API, так как этот подход является более распространенным из-за своей относительной простоты и удобства для разработчиков. SOAP API преимущественно характерен для больших корпоративных (enterprise) систем.
Чем работа с API может быть полезна тестировщику?
Для начала постараемся понять, зачем вообще тестировщику осваивать что-либо на таком уровне. Казалось бы, программные интерфейсы – это территория разработчиков. Ниже мы рассмотрим выгоды использования тестирования API.
Выгода первая: точная локализация.
Умение работать с API позволяет лучше понимать и точнее описывать возникшие ошибки. Предположим, вы открываете некую страницу сайта и видите в пользовательском интерфейсе сообщение об ошибке. Чем конкретно она вызвана? Насколько она серьезна? Может ли она отразиться на других частях системы? Нам будет гораздо проще ответить на эти вопросы, если мы сможем понять, какую именно функцию не удалось выполнить системе. Сообщения в графическом интерфейсе не всегда позволяют оценить эту зависимость.
Выгода вторая: экономия времени при подготовке тестовых данных и ситуаций.
Многие тесты требуют подготовки условий для их проведения. Так, для прохождения кейса про редактирование документа нам может потребоваться создать сам документ. В графическом интерфейсе это займет немало времени: придется, например, нажимать множество кнопок, чекбоксов, заполнять текстовые поля и т. д. По сути, мы выполняем лишь подготовительные действия для того, чтобы браузер отправил серверу запрос на создание документа. При этом сама отправка и исполнение запроса, как правило, занимает доли секунды.
Более того – многочисленные действия в браузере часто являются причиной ложных «падений» автоматизированных тестов, которым на уровне GUI свойственна «хрупкость». Одно неуспешное нажатие кнопки может привести к необходимости повторения либо всего теста, либо какой-то его части. Сформировав запрос программно или воспроизведя его с помощью специальных инструментов (об этом чуть позже), мы можем существенно сократить время проверки.
Выгода третья: возможность воспроизводить тесты на больших наборах входных данных.
Для некоторых проектов важно проводить тесты с большим количеством разнообразных наборов входных данных, отделенных от кода самого теста и вынесенных в отдельный файл. В этом случае один и тот же сценарий может повторяться многократно для разных значений. Эту методологию (так называемую Data Driven Testing) сложно реализовать через графический интерфейс с приемлемой скоростью и стабильностью. Напротив, на уровне http-запросов это делается очень быстро и с гораздо более высокой надежностью.
Практические шаги к освоению работы с REST API сайта
Итак, вы решили освоить работу с программным интерфейсом вашего сайта. С чего же начать?
Шаг 1: откройте средства разработчика в браузере.
Откройте средства разработчика (developer tools) в браузере (например, в Mozilla Firefox и Google Chrome просто нажмите F12) и перейдите во вкладку, в которой отражается сетевая активность (Network, Net, Сеть и т. д.)
Совершайте обычные действия в браузере и наблюдайте за результатом. Первое, что бросается в глаза, – это огромное количество запросов даже при загрузке одной страницы: для получения каждого изображения, стилей, шрифтов, структуры страницы, скриптов. При использовании AJAX (от англ. Asynchronous Javascript and XML – асинхронный JavaScript и XML, подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером) количество запросов может увеличиваться, даже если вы не производите никаких активных действий.
Шаг 2: скройте запросы, не относящиеся к логике работы.
Что же делать с огромным количеством запросов? Как выбрать те, которые для нас полезны? Попробуйте применить текстовый фильтр. Многие запросы, относящиеся к логике взаимодействия клиента и сервера (то есть, к API), могут содержать в своих URL фрагмент, указывающий на это (например, «api/rest»). Если вы обнаружили такой фрагмент – введите его в поисковую строку DevTools. Средства разработчика в браузере также позволяют выделить запросы определенного типа: XHR, JS, CSS, Images и т. д.
Выберите XHR (XMLHttpRequest) – это интерфейс языка JavaScript, используемый для конструирования запросов, имеющих тело. Обычно именно этот интерфейс используется для обращения к API. Вы можете столкнуться с большим количеством однотипных запросов, порождаемых различными системами мониторинга (например, yandex.webvisor). Их можно скрыть, применив негативный фильтр (например, «-yandex» для Chrome), даже если вы не знаете точно, что именно эти запросы делают. Однотипные и часто повторяющиеся запросы, как правило, относятся к мониторингу сайта, а не к логике совершаемых пользователем действий.
По клику на картинку откроется полная версия.
Просмотрите внимательно оставшиеся после применения фильтра запросы и постарайтесь выявить те, которые относятся именно к логике действий. В случае необходимости обратитесь за разъяснениями к разработчикам. Если вам доступна документация, в которой описываются endpoint-ы сервисов вашего проекта (т. е. адреса, к которым обращаются запросы, относящиеся к API), – изучите ее. Ниже я буду рассматривать вариант, когда подробной документации или соответствующих доступов у вас нет.
Достаточно часто по адресу endpoint-а можно догадаться, за что именно отвечает запрос к данному сервису. Например, адрес, содержащий фрагмент « api/rest/createContract », скорее всего, используется для создания договора, « api/rest/buildInfo » – для вывода информации о версии, установленной в текущий момент, а « api/rest/news/search » – для поиска новостей. Если трудно «выловить» нужный запрос в общей массе (а запросов к API тоже может быть немало) – очистите историю запросов перед совершением интересующего вас действия. Довольно быстро вы научитесь видеть нужные запросы и сопоставлять их с действиями в пользовательском интерфейсе.
Шаг 3: проведите более детальный анализ структуры запросов.
Обратите внимание на то, что часть запросов передает информацию только в запрошенном URL-е. В первую очередь, это GET-запросы, которые предназначены для получения определенного содержимого или запуска процесса. Классический пример – запрос на текстовый поиск. Его URL может выглядеть как « https://anysite.ru/search?keywords=my_query&itemsperpage=20 », где « ../search » – адрес поискового сервиса, « keywords=… » – текст запроса, « itemsperpage » – параметр, отвечающий за количество результатов, выводимых на одной странице.
С другой стороны, встречаются запросы, передающие большинство параметров в теле самого запроса. При этом часть параметров может передаваться и в URL. Примером могут послужить POST-запросы:
URL : POST https://www.youtube.com/feed_ajax?action_pause_watch_history=1 HTTP/1.1
Request headers : дополнительная информация, в т. ч. cookies.
Message Body :
session_token=QUFFLUhqbER0TE5idlp2MngybFh1ZUUyblYtaGlmLVhmZ3xBQ3Jtc0tta1J5W
m9uZHpVTW9oWHIzOWdIblkzVk1wVTNFQS1aS0pfNG85OWw3Sk14U2
В этом случае суть необходимого действия передается в URL-е ( action_pause_watch_history=1 ), а информация о пользователе – в теле запроса ( session_token ).
На структуру тела запросов и ответов не накладывается ограничений. Это может быть как просто набор пар поле/значение (т. н. Form Data, как в примере выше session_token/значение ), так и документ в удобном для разработчика формате (JSON, XML или каком-то ином).
Проанализируйте приходящие ответы (вкладка Response) и их коды. Помимо всего прочего, коды ответов, как правило, несут полезную информацию и сообщают о логике происходящего. Большинство запросов имеют код ответа «200 OK», сообщающий о том, что операция выполнена успешно. В случае возникновения ошибки коды будут начинаться на 4 (ошибка на стороне клиента) или на 5 (ошибка на стороне сервера). Например, таковы всем известные ошибки 404 («клиент запросил несуществующий ресурс») и 500 («внутренняя ошибка сервера»). Обратите внимание, что браузеры предоставляют возможность просмотра подробностей запросов/ответов как в удобном формате («parsed» в Google Chrome, «pretty print» в Mozilla Firefoх), так и в «сыром» виде («source»). Конечно, для понимания проще «parsed»/«pretty print», но в том случае, когда вам необходимо скопировать часть запроса, лучше переключиться в режим «source».
По клику на картинку откроется полная версия.
По клику на картинку откроется полная версия.
Шаг 4: воспроизведите запросы.
Итак, вы видите нужные запросы и понимаете, какие именно параметры они передают и с какой целью. Теперь можно попробовать самостоятельно менять значения параметров для получения нужных действий. Каким образом можно воспроизвести запросы с измененными параметрами? Самый простой способ — создавать GET-запросы, просто вводя их в адресную строку браузера (по сути, адресная строка – это интерфейс командной строки для воспроизведения GET-запросов). Но вам не удастся сделать многое, ограничившись лишь GET-методом.
Для расширения ваших возможностей используйте Fiddler или подобные ему инструменты (например, такие). Эти программы перехватывают весь сетевой трафик, позволяя просматривать, редактировать и воспроизводить отдельные запросы. Уже на этом уровне можно что-то тестировать – например, валидацию данных на стороне сервера. Если веб-клиент в браузере не позволил вам ввести некоторые значения – в Fiddler-е вы сконструируете запрос сами. Такой способ может существенно ускорить проверку большого набора данных для ввода, особенно если изменение значений в браузере занимает длительное время.
По клику на картинку откроется полная версия.
Дальше – автоматизация тестирования REST API!
Постигнув принципы работы API, вы можете использовать эти навыки в автоматизированных тестах. Остается выбрать инструменты, которые будут воспроизводить нужные вам запросы и отслеживать содержимое ответов. Если вы умеете писать автоматизированные тесты для графического интерфейса (например, с использованием Selenium), то идеальным вариантом, на мой взгляд, будет интеграция тестов API в существующий фреймворк. Тесты часто содержат подготовительные/вспомогательные действия, многие из которых удобнее выполнить с использованием API. Это будет быстрее и стабильнее.
С другой стороны, механизм авторизации бывает достаточно сложным, его не всегда легко пройти только с помощью запросов. Но и это не представляет проблемы в том случае, если API-тесты интегрированы с тестами GUI. Нужные cookie можно забрать в браузере, открытом с помощью Selenium ( driver.manage().getCookieNamed(«sessionId»).getValue() ).
protected ExtractableResponse postRequest(String requestPayload, String endpoint, int expectedStatus) <
return
given().
auth().basic(«login», «password»).
cookies(«sessionId», session).
contentType(ContentType.JSON).
body(requestPayload).
relaxedHTTPSValidation().
when().
post(endpoint).
then().
statusCode(expectedStatus).
body(containsString(«www»)).
extract();
>
Например, вы можете проверить, соответствует ли статус ответа ожидаемому ( statusCode(expectedStatus) ) и содержит ли тело ответа определенный фрагмент текста ( body(containsString(«www»)) ). Команда extract() позволяет получить ответ и использовать его, например, для извлечения определенных значений.
Это можно сделать следующим образом:
ExtractableResponse response = postRequest(session, payload, endpoint, 200);
int numberOfResults = response.path(«results.total»);
Стоит отметить, что и Java, и Python имеют средства работы с http в числе стандартных возможностей, но я неоднократно сталкивался с мнением, что они не слишком удобны. Если вы не планируете писать тесты с использованием языка программирования, то вам, скорее всего, подойдет инструмент Postman – он позволяет воспроизводить и сохранять запросы, а также выстраивать из них тесты.
Заключение
Все сказанное выше позволяет сделать следующий вывод: умение тестировщиков работать с API может принести пользу практически любому проекту. Например, это дает возможность в считанные минуты провести смоук (и убедиться, что ничего важного не сломалось), выполнить одни и те же тесты с разнообразными наборами входных данных или быстро проделать какие-либо вспомогательные действия по созданию тестовых данных и ситуаций.
Наконец, еще раз хочу напомнить, что тестирование API становится особенно востребованным в свете растущей популярности микросервисной архитектуры. Следовательно, даже в том случае, если на вашем проекте пока не используется тестирование на уровне API, вам имеет смысл присмотреться к возможностям, которые оно предоставляет.