0: Http web сервисы это ещё 1 инструмент интеграции. Аштитипи сервисы используют архитектурный стиль. Rest это не протокол, а набор соглашений и принципов при использовании http сервисов разработчик сам должен спроектировать протокол, какая архитектура будет.

1: Http запросов, как будут возвращаться ошибки, будет ли реализована валидация входящих и исходящих данных и прочие соглашения. Веб сервисы используют протокол soap, в котором реализовано все вышеперечисленное. Преимущества веб сервисов удобнее использовать при обе

2: Между системами на базе 1 эс готовая спецификация реализованные методы проверок данных, обработки ошибок, автодокументация сервиса, недостатки из за более сложной реализации может проигрывать скорости. Http сервису суап должен быть реализо.

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

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

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

6: Задачами сотрудников. Вывод списка задач, добавление и удаление задачи для сравнения процесса реализации, размеры содержимого аштипи пакетов. Реализую 1 и ту же задачу 2 способами на http и soap начну с http сервиса перед началом

7: Разработки опишу спецификацию, используя open апи и инструмент для работы с openapi swagger проще говоря, опенапи это спецификация по разработке спецификаций, разработанная спецификация будет использоваться как документация для универсальной проверки параметров.

8: Запроса редактор сваги разбит на 2 части слева спецификация на языке ямал, справа документация, которая генерируется на лету, в спецификации указываются пути, запросы, параметры и структуры json объектов.

9: Спецификация апи для моей задачи такая запрос таск методом get выводит список задач, содержит 2 необязательных параметра id для отбора по сотруднику и dan для отбора по признаку выполнено, возвращает код.

10: P. 200 и массив объектов типа task запрос, таск методом post добавляет задачу данные о новой задаче передаются через тело запроса в виде json объекта, возвращает код типи 200 если не было ошибок, если были ошибки, возвращает код.

11: 400 и массив ошибок запрос таск методом delete удаляет задачу, содержит 1 обязательный параметр id задачи возвращает код http 200 если не было ошибок, если были ошибки, возвращает код 400 и массив ошибок в разделе, схема описаны.

12: Json объекты теперь можно приступить к реализации на 1 эс для моей задачи запрос будет выглядеть так, где вер 1 это версия api, добавлю аштитипи сервис.

13: Часть ула, отвечающую за версию, добавлю в корневой урл, так как она будет общая для всех запросов.

14: Например, при расширении моего примера запросы могут выглядеть так добавлю шаблон для части la task теперь реализую методы запроса метод get.

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

16: В цикле заполняется структура объектов и помещается в массив реализую сами функции, возвращающие структуры данных согласно спецификации.

17: Тело ответа передаётся сериализованный массив структур метод пост.

18: Джейсон из тела запроса здесь реализуется в структуру.

19: Если указанный в запросе сотрудник найден, создаётся задача в поле file могут находиться двоичные данные в кодировке бс 64. Это будут данные картинки, если строка не пустая, получаю бинарные данные из кодированной строки, помещаю в хранилище значения.

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

21: Код 400, то есть код ошибки в теле передаётся массив строк с описанием ошибок метод delete.

22: Получаю параметр id и проверяю его значение на соответствие спецификации алгоритм работы проверки спецификация в формате json находится в общем макете, она дистиллируют. Я в структуру. Далее в этой структуре ищется проверяемый параметр, если

23: По спецификации он обязательный, а по факту не заполнен, возвращается текст ошибки.

24: Если проверка не прошла, формируются ошибки.

25: Если переданная для удаления задача найдена, она удаляется, иначе формируются ошибки. Публикация сервиса я использую сервер на linux, поэтому сначала сохраню шаблон для публикации, файл и выполню публикацию через консоль с указанием файла шаблона немного.

26: Теории по структуре пакета аштитипи аштитипи это текстовый протокол, использующий протокол tcp как transport http пакет это просто текст определённой структуры, стартовая строка с указанием метода и версии далее идёт заголовок пакета, состоящий из набора параметров.

27: Потом пустая строка как разделитель заголовка и тела, и после неё тело пакета тело может содержать любые данные в текстовом формате, например, html, json или бинарные данные в виде кодированной строки далее текст аштипи пакета кодируется в массив байт и передаётся.

28: Protocol tcp тестирование api для тестирования я буду использовать инструмент постман, вывод, списка задач указываю запрос методом get список пустой, так как ещё ничего не было добавлено для добавления выбираю метод, пост в теле запроса, указ.

29: Данные новой задачи.

30: А именно её описание id ответственного сотрудника и картинку, закодированную в б. 64 данные картинки получу через функцию 1 с. Б. 64 строка бинарные данные необходимо передавать в виде кодированной строк.

31: Так как http это текстовый протокол, проверяю метод get вывод списка.

32: Добавлю фильтр по сотруднику.

33: Метод delete в параметрах указываю айди и код задачи.

34: Укажу несуществующую задачу и получу ответ с ошибкой и код аштипи 400.

35: Отключу параметр и также получу ошибку в сваггер также можно протестировать апи прямо из документации, например, метод.