API.

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

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

Взаимодействие с внешними сервисами.

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

Расширение функциональности.

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

Интеграция с аппаратным обеспечением.

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

Обмен данными.

API часто применяются для обмена данными между различными частями одной программы или между разными программами.

API могут быть реализованы разными способами, включая веб-сервисы, библиотеки, SDK (Software Development Kit) и другие средства. Они обычно документированы, чтобы разработчики могли понять, как ими пользоваться, и какие функции они предоставляют.

Различия между протоколами API.

REST и SOAP.

Существует два основных подхода к построению веб-приложений:

REST архитектурный стиль, обеспечивает общение между клиентом и сервером с помощью обычных HTTP-запросов (GET, POST, PUT, DELETE и т.д), передавая информацию от клиента в параметрах самих запросов (таких как строка запроса или тело запроса), а информацию от сервера — в теле ответа.
SOAP является протоколом и имеет спецификацию. Все детали сообщений (в обе стороны — от клиента к серверу и обратно) передаются в стандартизованном XML-документе. SOAP используется для обмена произвольными сообщениями в формате XML.

Корректное SOAP-сообщение состоит из нескольких структурных элементов: Envelope, Header, Body и Fault.

Envelope («конверт»). Это корневой элемент. Определяет XML-документ как сообщение SOAP с помощью пространства имен.
Header («заголовок»). Включает в себя атрибуты сообщения, связанные с конкретным приложением (аутентификация, проведение платежей и так далее).
Body («тело»). Сообщение, которое передает веб-приложение. Может содержать запрос к серверу или ответ от него.
Fault («ошибка»). Опциональный элемент. Передает уведомление об ошибках, если они возникли в ходе обработки сообщения.

Отличия REST и SOAP.

Данные в REST можно передавать в различных форматах: JSON, XML, HTML, текст, а в SOAP только XML.
REST работает только по HTTP(-S), SOAP с различными протоколами.
SOAP — это протокол, REST — это архитектурный стиль.
Ответ при использовании SOAP не может быть помещен в кэш, а REST в этом случае может быть закэширован.

RESTful.

Принципы (6) RESTful API (Representational State Transfer).

RESTful API основаны на принципах архитектуры REST и используют стандартные HTTP методы (GET, POST, PUT, DELETE) для взаимодействия с ресурсами. Они часто используются для веб-сервисов и взаимодействия с данными в формате JSON или XML. (набор рекомендаций, свободная структура).

Клиент-серверная модель.
Отсутствие состояния.
Кэширование.
Единообразие интерфейса.
Многоуровневая система.
Код по требованию.

GraphQL.

Это современный протокол, который позволяет клиентам запрашивать только те данные, которые им нужны. Вместо предоставления фиксированных точек доступа, как REST, GraphQL дает клиентам гибкость создавать свои запросы
.(запросы:query-get,mutation-post)

JSON-RPC и XML-RPC.

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

XML.

XML (англ. eXtensible Markup Language) — расширяемый язык разметки. Используется для хранения и передачи данных. XML — всегда используется в SOAP и иногда в REST-запроса. Документы в форматах HTML и XML содержат данные, заключенные в теги, но на этом сходство между двумя языками заканчивается.

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

Тега всегда два: открывающий и закрывающий.

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

<?xml version="1.0"?>
<user>
  <name>Иван</name>
  <surname>Иванов</surname>
  <age>25</age>
  <birthplace>Курск</birthplace>
  <married>true</married>
</user>

XML Schema.

XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных.

Такой подход позволяет объектно-ориентированным языкам программирования легко создавать объекты в памяти, что, несомненно, удобнее, чем разбирать XML как обычный текстовый файл.
Кроме того, XSD расширяем, и позволяет подключать уже готовые словари для описания типовых задач, например веб-сервисов, таких как SOAP.

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

JSON.

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования. Для хранения данных в JSON используются две структуры — объекты и массивы.

Данный XML будет идентичен следующему JSON:

{
  "name": "Иван",
  "surname": "Иванов",
  "age": 25,
  "birthplace": "Курск",
  "married": true
}

JSON Schema.

Схема JSON — это мощный инструмент для проверки структуры данных JSON.

Как проверить валидацию JSON?

Для проверки строки на валидность в отношении формата JSON в JavaScript, рекомендуется использовать функцию JSON. parse() в связке с конструкцией try.. catch . Если разбор выполняется успешно, возвращаем true, в противном случае — false.

Отличия JSON и XML.

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

Основные характеристики REST API.

В REST API всё представлено в виде ресурсов, которые могут быть идентифицированы уникальными URL-адресами. Ресурсы могут быть, например, объектами, документами или коллекциями данных.
REST использует стандартные методы HTTP для выполнения операций над ресурсами. Наиболее часто используемые методы: GET, POST, PUT, DELETE.
REST API обычно работает с данными, представленными в формате JSON или XML. Ответы от сервера содержат данные, а клиенты могут отправлять данные серверу при создании или обновлении ресурсов.
RESTful сервисы не сохраняют состояние между запросами. Каждый запрос от клиента должен содержать все необходимые данные для выполнения операции. Это делает их более масштабируемыми и легче в поддержке.
REST API обладают унифицированным интерфейсом, что означает, что клиенты и серверы могут взаимодействовать между собой, следуя общим правилам, без необходимости знания подробностей реализации.

Концепции Rest Api.

Модель взаимодействия (Клиент-Сервер).
Система может быть многоуровневой.
Отсутствие состояния (каждый раз клиент и сервер общаются как в первый раз).
Единообразный унифицированный интерфейс.
Кеширование.
Формат обмена данными — Json.
Версионирование.

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

Проверить корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
Проверить полезную нагрузку ответа. Проверить правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
Проверить заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
Проверить правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
Проверить базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.

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

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

Основные позитивные тесты (прохождение успешного сценария по умолчанию).
Расширенное позитивное тестирование с дополнительными параметрами.
Негативное тестирование с валидными входными данными.
Негативное тестирование с недопустимыми входными данными.
Деструктивное тестирование.
Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи).

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

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

Изолированное тестирование запросов.

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

Многоступенчатый рабочий поток с несколькими запросами.

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

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

Комбинированные тесты API и тесты веб-интерфейса.

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

Безопасность и авторизация.

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

Позитивные тесты.

Убедиться, что API отвечает на правильную авторизацию всеми согласованными методами аутентификации — ответный токен auth 2.0, файлы cookie, дайджест и т. д. — как определено в спецификации.

Негативные тесты.

Убедиться, что API отклоняет все несанкционированные вызовы.

Ролевые доступы: убедиться, что определенные конечные точки доступны пользователю в зависимости от роли. API должен отклонять вызовы конечных точек, которые не разрешены для роли пользователя.

Проверка протокола: проверить HTTP / HTTPS в соответствии со спецификацией

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

Использовать в поле Name пробел.
Изменить пол с Female на Male.
Отправить запрос без токена.
Отправить запрос с измененным токеном (неверным).
Отправить запрос не заполняя все обязательные поля.
Изменить поле Status c Active на Neactive.
Отправить запрос с измененным email.
Ввести в поле Name значение из 100 символов, как пример.
Изменить формат отправки данных с JSON на XML.
Отправить запрос с пустым Header.
Отправить не POST запроса GET.

Производительность.

Проверка времени ответа API, задержки, TTFB / TTLB в различных сценариях (изолированно и под нагрузкой)

Нагрузочные тесты (позитивные), стресс-тесты (негативные).

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

Юзабилити-тесты пользователей API.

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