# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА: + АРХИТЕКТУРА + Vision + Solution Design + ESB + Микросервисы и service mesh - HTTP/REST | Инструменты для тестирования web-API | Базовые понятия | Основы HTTP | Что ж такое REST? + RPC + DDD ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
HTTP/REST
latest update of the page: 13-03-2024, 20:51 UTC
Инструменты для тестирования web-API

Postman

GUI-инструмент для тестирования REST/SOAP. Поддерживает создание скриптов для автотестов (Javascript).

SoapUI

GUI-инструмент для тестирования REST/SOAP. Поддерживает создание test-suit'ов со скриптами для автоматизации тестирования (разные ЯП).

curl

CLI-инструмент для для взаимодействия с серверами по протоколам с синтаксисом URL.

# отправить GET-запрос, содержащий заголовок с JWT (JSON Web Token) curl -H GET https://localhost:8080/some -H "Authorization: <JWT>" -i

# отправить GET-запрос, содержащий имя пользователя user и его пароль pass прямо в командной строке (антисекурно) curl -u "user:pass" -H GET https://localhost:8080/some -i

# отправить GET-запрос, содержащий имя пользователя user, а пароль curl спросит при отправке, он не будет виден на экране и останется в истории команд консоли curl -u "user" -H GET https://localhost:8080/some -i

# отправить POST-запрос с телом запроса из определённого файла и с заголовком, объявляющим, что мы несём JSON curl -X POST https://localhost:8080/createSomething -H "Content-Type: application/json" -d "@data.json" -i

# отправить POST-запрос с телом запроса, указанном прямо в строке, и с заголовком, объявляющим, что мы несём JSON curl -X POST https://localhost:8080/createSomething -H "Content-Type: application/json" -d '{"somefield":"somevalue"}' -i

# url encode curl -X GET "https://1.1.1.1:8080/find" -G --data-urlencode "param=123 abc" -i

Базовые понятия

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

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

TCP/IP = набор сетевых протоколов передачи данных.
Стек протоколов TCP/IP включает в себя четыре уровня:

  • прикладной уровень (Application layer): HTTP, FTP, HTTPS, DHCP, IMAP, IRC, NTP, POP3, Telnet, SSH, DNS (преобразование символьных имён в IP-адреса, IP-адрес — уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP);
    The protocols used by host processes to communicate over the network. The application may be architected as a client-server system, or as a peer-to-peer system. At this layer, usually, a human readable hostname (e.g. www) and domain name (e.g. acme.com) are combined to into a fully qualified name (i.e. www.acme.com) to identify the host.
  • транспортный уровень (Transport layer): UDP, TCP (в отличие от UDP гарантирует целостность передаваемых данных и уведомление отправителя о результатах передачи: делает повторный запрос в случае утери данных, устраняет дублирование при получении двух копий одного пакета), SCTP, DCCP;
     The protocols with which hosts can communicate end-to-end, and make corrections for packets lost in the underlying network. The most used protocols are the connection-oriented Transport Control Protocol (TCP) and the connectionless Unified Datagram Protocol (UDP). At this layer, a logical ‘port number’ is used to identify a specific communication end-point.
  • сетевой уровень (Network layer): Для TCP/IP это IP;
     The Internet Protocol (IP) specifies the common connectionless protocol that provides best effort packet delivery across network boundaries. Best effort implies packets may be lost, corrupted, delivered out of order, or in some cases, duplicated. The two basic functions of this protocol are to identify hosts using their IP Address; and to set up routing tables to determine how packets should be forwarded between nodes.
  • канальный уровень (Data link layer): Ethernet, IEEE 802.11 Wireless Ethernet, SLIP, Token Ring, ATM и MPLS, T1, E1;
     The medium specific protocols that concerns with communicating with neighbouring hosts on the same local network without any intervening routers or gateways. E.g. the Address Resolution Protocol and the Point-to-Point Protocol. At this layer, nodes are identified by a physical address -- typically the MAC (Medium Access Control) address.

URL состоит из протокола (protocol), хоста (host), пути (path), запроса (query) и фрагмента. Путь используется для организации иерархических ресурсов, запрос — для неиерархических ресурсов и для параметров операции. Фрагмент идентифицирует подчинённый ресурс, не имеющий прямого URL, обычно это якорная ссылка на странице.

Protocol    Host                 Path               Query      Fragment
  ↓           ↓                    ↓                  ↓            ↓
http://nyashnye-kotiki.xxx/breeds/maine-coon/?deliver_to=Moscow#photo

Основы HTTP

HTTP (HyperText Transfer Protocol — "протокол передачи гипертекста") — прикладной протокол передачи данных. Основой HTTP является технология "клиент-сервер", то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Эта диаграмма отображает простейшую архитектуру веб-приложения:

Веб-Клиент отправляет запрос к Веб-Серверу, а тот ему отвечает.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

  1. Стартовая строка (Starting line) — определяет тип сообщения, является обязательным элементом сообщения;
  2. Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
  3. Тело сообщения (Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Стартовая строка для запроса (от клиента): <method> <URI> HTTP/<version>
Пример: GET /path/resource?param1=value1&param2=value2 HTTP/1.1
Стартовая строка для ответа (от сервера): HTTP/<version> <КодСостояния> <Пояснение>
Пример: HTTP/1.0 200 OK

Общая структура запроса:

Общая структура ответа: Где: lf = перевод строки, Sp = пробел (space)

Обычный GET-запрос.
Запрос клиента: GET /wiki/страница HTTP/1.1 Host: ru.wikipedia.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close (пустая строка) Ответ сервера: HTTP/1.1 200 OK Date: Wed, 11 Feb 2009 11:20:59 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close (пустая строка) (HTML-код запрошенной страницы)

Методы HTTP-протокола

HTTP-протокол (начиная с версии 1.1) оперирует методами OPTIONS , GET , HEAD , POST , PUT , PATCH , DELETE , TRACE , CONNECT (ссылки на RFC).

GET используется для запроса данных с указанного адреса ресурса.
Клиент МОЖЕТ передавать параметры запроса прямо в первой строке запроса в URI целевого ресурса после символа "?": GET /path/resource?param1=value1&param2=value2 HTTP/1.1

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

POST применяется для передачи ДАННЫХ В ТЕЛЕ ЗАПРОСА по заданному адресу.
Например, оставить комментарий на форуме. Аналогично с помощью метода POST обычно загружаются файлы на сервер. Сервер уже сам решает что с вашими данными делать. POST forum.com/threads/gameofthrones/messages Обратите внимание, если вы по ошибке или вследствие сетевых проблем повторите POST запрос — создастся второе сообщение в треде, идентичное первому.

PUT применяется для отправки некоторых данных на конкретный указанный в запросе URI. Если по заданному URI не существует ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). PUT forum.com/threads/gameofthrones/messages/100500 PUT вы можете делать хоть 500 раз, в нашем примере — форумный пост всё равно будет один. Это свойство называется идемпотентностью.
PUT может использоваться как для создания новых ресурсов, так и для обновления старых. Однако в случае использования PUT для перезаписи предполагается, что в теле запроса передаётся закодированный ресурс целиком.

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

HTTP CRUD Ответы для всей коллекции
(/customers)
Ответы для конкретного ID
(/customers/{id})
Примеры запросов
POST Create 201 (Created), 'Location' header со ссылкой на /customers/{id} содержащей новый ID 404 (Not Found),
409 (Conflict) если ресурс уже существует
POST http://site.com/customers
POST http://site.com/customers/123/orders
GET Read 200 (OK), список Клиентов 200 (OK).
404 (Not Found) если ID не найден или неправилен
GET http://site.com/customers/123
GET http://site.com/customers/123/orders
PUT Update
/Replace
405 (Method Not Allowed), разве только вы не захотите обновить/заменить каждый ресурс во всей коллекции 200 (OK) или 204 (No Content).
404 (Not Found) если ID не найден или неправилен
PUT http://site.com/customers/123
PUT http://site.com/customers/123/orders/98765
PATCH Update
/Modify
405 (Method Not Allowed), раазве только вы не заходите изменить саму коллекцию 200 (OK) или 204 (No Content).
404 (Not Found) если ID не найден или неправилен
PATCH http://site.com/customers/123
PATCH http://site.com/customers/123/orders/98765
DELETE Delete 405 (Method Not Allowed), разве только вы не захотите удалить всю коллекцию. 200 (OK).
404 (Not Found) если ID не найден или неправилен
DELETE http://site.com/customers/123
DELETE http://site.com/customers/123/orders
HEAD
OPTIONS
TRACE
CONNECT

Что ж такое REST?

REST (Representational State Transfer — "передача репрезентативного состояния") = архитектурный стиль построения распределённых приложений, имеющий 6 ограничений, дающих (по заявлению автора) большую производительность и масштабируемость системы.

Ограничения, соблюдение которых дают веб-сервису "право" называться RESTful:

  1. Клиент-серверная модель (client-server architecture)
    Есть Сервер, имеющий некие данные. Есть Клиент, которому необходимы эти данные для работы. Они взаимодействуют с помощью запросов и ответов. При этом код Клиента и Сервера развиваются независимо друг от друга, что даёт гибкость таким системам.
  2. Отсутствие состояния (Statelessness).
    Сессия хранится на Клиенте.
    Каждый запрос рассматривается Сервером как самостоятельный, при этом запрос должен иметь все необходимые атрибуты для возможности обработки операции на стороне Сервера.
  3. Единообразие интерфейса (uniform interface).
    1. Идентификация ресурсов. Все ресурсы (данные) на Сервере имеют идентификаторы, Клиент может обращаться к конкретному ID ресурса в запросе, например, с использованием URI. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам, например, сервер может отсылать данные в виде HTML, XML, JSON, JPG, и при ни один из них не является типом хранения внутри Сервера.
    2. Манипуляция ресурсами через представление. Если Клиент хранит представление ресурса, включая метаданные, то он обладает достаточной информацией для модификации или удаления ресурса. Например, Клиент отправляет в запросе представление в JSON-объекта, содержащего данные ресурса, который он бы хотел добавить/изменить/удалить.
    3. Самоописываемые/самодостаточные сообщения. Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. В том числе, например, явно указывая обработчик сообщения (parser), необходимый для извлечения данных из пересылаемой структуры, для HTML это может быть, например, метатег content-type = text/html.
    4. Гипермедиа. Ответы Сервера могут содержать данные, являющиеся ссылками на ресурсы, например теги a в HTML-разметке.
  4. Возможность кэширования (Cacheability).
    Клиент, как и промежуточные узлы, могут выполнять кэширование ответов Сервера. Ответы должны иметь (не)явное обозначение кэшируемости.
  5. Система слоёв (Layered system).
    В системе м.б. большее количество слоёв чем Клиент+Сервер. Например, шлюзы, прокси, балансировщики. Которые могут заниматься балансировкой нагрузки на Сервер, выполнять функции безопасности, распределённое кэширование и т.п.
  6. Код по требованию (code on demand). Ограничение принято не считать обязательным.
    Предполагает возможность отправки Сервером исполняемого кода Клиенту, например javascript, который Клиент может выполнить.