--- title: SOAP и REST seo: title: SOAP и REST — Systems Analyst description: Тема «SOAP и REST» для собеседования Systems Analyst. Чем SOAP отличается от REST? Из чего состоит сообщение в SOAP? --- [Все темы Systems Analyst](/systems-analyst) ## Чем SOAP отличается от REST? [#q-14bee738d69b810d97d7dff034ade1ac] SOAP (Simple Object Access Protocol) и REST (Representational State Transfer) - это два различных подхода к веб-сервисам: {/* prettier-ignore */} 1. Протокол обмена данными: - SOAP: Использует протокол SOAP для обмена структурированными сообщениями (XML) по сети. - REST: Основан на принципах HTTP и использует стандартные методы HTTP (GET, POST, PUT, DELETE) для доступа к ресурсам. 1. Формат сообщений: - SOAP: Сообщения SOAP обычно представлены в XML формате и часто содержат метаданные о структуре данных. - REST: Возвращает данные в различных форматах, таких как JSON, XML, HTML или текст, в зависимости от запроса клиента. 1. Управление состоянием (State): - SOAP сам по себе не требует сохранения состояния между вызовами. Сессионное поведение может задаваться приложением или дополнительными спецификациями. - REST является архитектурным стилем. Ограничение stateless требует, чтобы каждый запрос содержал контекст для обработки; сервер при этом может хранить ресурсы и бизнес-данные. 1. Простота и гибкость: - REST: Считается более простым и гибким в сравнении с SOAP, так как основывается на стандартных HTTP методах и форматах данных. - SOAP: Предоставляет большую структурированность и четкость в обмене сообщениями, что может быть полезно в сложных интеграционных сценариях. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Из чего состоит сообщение в SOAP? [#q-14bee738d69b81edb857f32ca79eb78f] Сообщение в SOAP (Simple Object Access Protocol) состоит из трех основных частей: 1. Envelope (Оболочка): Определяет структуру XML-документа и обязательно присутствует в каждом SOAP-сообщении. Включает информацию о версии SOAP и пространствах имен. 1. Header (Заголовок): Опциональная часть, которая содержит метаданные или информацию о маршрутизации и обработке сообщения, такие как аутентификация, транзакционные данные и другие параметры. 1. Body (Тело): Содержит основное содержимое сообщения, которое передается между отправителем и получателем. Обычно это XML-документ с данными, которые требуется обработать или передать. SOAP-сообщение часто используется для интеграции между различными системами и является стандартом для обмена структурированными и комплексными данными по сети. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Что содержит HEADER в ответе REST? [#q-14bee738d69b817686a9f822b0733022] В ответе REST, заголовок (HEADER) может содержать различные метаданные и управляющие данные, такие как: 1. Статус ответа передаётся отдельно от обычных полей заголовков: в строке статуса HTTP/1.1, а в HTTP/2 и HTTP/3 в псевдозаголовке :status. 1. Кэширование: Заголовки Cache-Control, Expires и ETag могут использоваться для управления кэшированием ответа на клиентской стороне. 1. Аутентификация: WWW-Authenticate в ответе задаёт запрос аутентификации. Authorization обычно передаётся клиентом в запросе. 1. Тип содержимого: Заголовок Content-Type указывает на тип возвращаемого контента (например, application/json для JSON или text/xml для XML). 1. Перенаправление: Location указывает URI, на который следует перейти. Стандартного поля ответа Redirect для этого нет. 1. Дополнительные данные: Другие заголовки могут содержать различные метаданные, такие как дата и время ответа, сервер и прочее. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Чем отличаются HTTP-статусы 200 OK и 201 Created? [#q-14bee738d69b81fab719c23847c8e67a] 200 OK и 201 Created относятся к успешным HTTP-ответам: {/* prettier-ignore */} 1. 200 OK: - Этот статус указывает, что запрос клиента успешно обработан сервером. - Обычно используется для ответа на запросы типа GET, POST, PUT или DELETE. - При успешной обработке запроса сервер возвращает запрашиваемые данные в теле ответа. 1. Код состояния 201 (Created): - Этот статус указывает, что сервер успешно создал новый ресурс по указанному клиентом запросу. - Часто используется после успешного выполнения операции POST, когда создается новый объект или запись в базе данных. - В теле ответа может содержаться информация о созданном ресурсе, а также ссылка на него. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Какие методы REST вы знаете? [#q-14bee738d69b8184a9a9ff027c3449cd] В архитектуре REST (Representational State Transfer) используются следующие основные методы (или операции), которые описывают типы действий, которые клиенты могут выполнить с ресурсами на сервере: 1. GET: Получение данных или ресурсов с сервера. Операция не должна изменять состояние сервера. 1. POST: Создание нового ресурса на сервере. Обычно используется для отправки данных на сервер для последующего сохранения. 1. PUT: Обновление существующего ресурса на сервере. Полностью заменяет текущее состояние ресурса на новое. 1. PATCH: Частичное обновление существующего ресурса на сервере. Используется для изменения только части ресурса без его полной замены. 1. DELETE: Удаление ресурса с сервера. Операция удаляет указанный ресурс. Эти методы позволяют клиентам взаимодействовать с ресурсами на сервере, изменять и получать данные с учетом REST-принципов, таких как унификация интерфейса и отсутствие состояния на сервере (statelessness). :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Чем POST отличается от GET? [#q-14bee738d69b81589a10f188922d1821] POST и GET - это два основных HTTP метода, используемых в архитектуре REST для взаимодействия с веб-ресурсами. Они имеют следующие различия: {/* prettier-ignore */} 1. GET: - Используется для запроса данных с сервера. - Параметры запроса передаются в URL как часть строки запроса (query string). - Ограничен по длине данных, которые можно передать в URL. - Кэшируется браузером, что облегчает повторное использование данных. - Не должен использоваться для отправки конфиденциальных данных, так как данные передаются в URL и могут быть видны в истории браузера или логах сервера. 1. POST: - Используется для отправки данных на сервер для обработки или сохранения. - Параметры запроса передаются в теле запроса (request body). - Размер тела ограничивается настройками клиента, прокси и сервера; универсального неограниченного объёма нет. - Ответ POST может быть кешируемым при явно заданных условиях, но многие кеши поддерживают только GET и HEAD. - Тело POST не попадает в адресную строку, но само по себе не защищает данные. HTTPS шифрует при передаче и тело, и URL-путь с query; приложение и сервер всё равно могут их журналировать. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Чем PUT отличается от PATCH? [#q-14bee738d69b81e7a7f9d7522d2594f0] PUT и PATCH - это HTTP методы, используемые для обновления ресурсов на сервере в архитектуре REST. Они отличаются следующим образом: {/* prettier-ignore */} 1. PUT: - Используется для полного обновления существующего ресурса на сервере. - При выполнении запроса PUT клиент отправляет целевой ресурс с полными данными (полное представление ресурса). - Если ресурс существует, он заменяется новыми данными, которые клиент передал. - Если ресурс не существует, PUT может создать новый ресурс с указанным идентификатором. 1. PATCH: - Используется для частичного обновления существующего ресурса на сервере. - При выполнении запроса PATCH клиент отправляет только ту часть данных, которую необходимо изменить (частичное представление ресурса). - PATCH применяет изменения к ресурсу, не затрагивая остальные его аспекты. - При этом PATCH может использовать операции добавления, замены, удаления частей данных ресурса в соответствии с протоколом JSON Patch или другими спецификациями. :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) ::: --- ## Напишите пример REST-API для книжной библиотеки (напишите методы, эндпоинты и пример JSON). [#q-14bee738d69b815586e5d9e2c6cb9cc9] Пример REST API для книжной библиотеки может включать следующие методы, эндпоинты и примеры JSON: {/* prettier-ignore */} 1. Получение списка всех книг - Метод: GET - Эндпоинт: /books - Пример JSON ответа: ```json [ { "id": 1, "title": "1984", "author": "George Orwell", "genre": "Science Fiction" }, { "id": 2, "title": "To Kill a Mockingbird", "author": "Harper Lee", "genre": "Classic" } ] ``` 1. Получение информации о конкретной книге по ID - Метод: GET - Эндпоинт: /books/{id} - Пример JSON ответа: ```json { "id": 1, "title": "1984", "author": "George Orwell", "genre": "Science Fiction", "isbn": "978-0451524935", "published_year": 1949 } ``` 1. Добавление новой книги - Метод: POST - Эндпоинт: /books - Пример JSON запроса: ```json { "title": "The Great Gatsby", "author": "F. Scott Fitzgerald", "genre": "Classic", "isbn": "978-0743273565", "published_year": 1925 } ``` - Пример JSON ответа (новая книга с ID): ```json { "id": 3, "title": "The Great Gatsby", "author": "F. Scott Fitzgerald", "genre": "Classic", "isbn": "978-0743273565", "published_year": 1925 } ``` 1. Обновление информации о книге - Метод: PUT - Эндпоинт: /books/{id} - Пример JSON запроса: ```json { "title": "The Great Gatsby", "author": "F. Scott Fitzgerald", "genre": "Classic", "isbn": "978-0743273565", "published_year": 1925 } ``` 1. Удаление книги - Метод: DELETE - Эндпоинт: /books/{id} :::note[Ссылки для изучения] 1. [Как аналитику работать с задачами на интеграции](https://habr.com/ru/articles/735332/) :::