что такое api rest soap
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns. Паттерны связывают HTTP методы с тем, что они делают.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
Что такое api rest soap
Eсть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:
Подробнее:
REST (Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине.
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса.
Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API.
REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют стандарты, такие как HTTP, URL, JSON и XML.
Требования архитектуры REST:
5. Слои
Клиент обычно не способен точно определить, взаимодействует он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации.
6. Код по требованию (необязательное ограничение).
REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или сценариев.
Приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями.
Если же все условия соблюдены, то приложение получает следующие преимущества:
Преимущества:
• Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);
• Производительность (за счёт использования кэша);
• Масштабируемость;
• Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
• Простота интерфейсов;
• Портативность компонентов;
• Лёгкость внесения изменений;
• Способность эволюционировать, приспосабливаясь к новым требованиям (на примере Интернет).
SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде.
Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
SOAP является одним из стандартов, на которых базируются технологии веб-служб.
Сравнение архитектурных стилей API: SOAP vs REST vs GraphQL vs RPC
Feb 4 · 12 min read
Два отдельных приложения нуждаются в посреднике, чтобы общаться друг с другом. Поэтому разработчики часто строят мосты — программные интерфейсы приложений, они же API, — чтобы предоставить одной системе доступ к информации или функциональности из другой.
Чтобы способствовать быстрой и масштабной интеграции приложений, API реализуются с использованием протоколов и/или спецификаций, определяющих семантику и синтаксис передаваемых сообщений. Эти спецификации составляют архитектуру API.
Со временем появились различные архитектурные стили API. Каждый из них содержит собственные схемы стандартизации обмена данными. Наличие выбора вызывает бесконечные споры о том, какой архитектурный стиль лучше.
Сегодня многи е пользователи API называют REST “Rest in peace” (“Покойся с миром”) и болеют за успех GraphQL, в то время как десять лет назад ситуация была обратной: REST как победитель, пришедший на замену SOAP. Проблема с этими мнениями в том, что они однобоко поднимают на щит какую-то технологию вместо того, чтобы рассматривать ее фактические свойства и характеристики относительно конкретной ситуации.
В этой статье мы останемся объективными и обсудим четыре основных стиля API в порядке их появления, сравним их сильные и слабые стороны и выделим сценарии, для которых каждый из них подходит лучше всего.
Удаленный вызов процедуры (RPC): вызов функции в другой системе
Удаленный вызов процедуры ( Remote Procedure Call) — это спецификация, которая позволяет удаленно выполнять функцию в другом контексте. RPC расширяет понятие локального вызова процедуры, но помещает его в контекст HTTP API.
Проблематичность первоначального XML-RPC связана со сложностями в обеспечении типов данных для полезных нагрузок XML. Позже API RPC задействовал более конкретную спецификацию JSON-RPC, которая считается более простой альтернативой SOAP. gRPC — последняя версия RPC, разработанная компанией Google в 2015 году. Благодаря подключаемым поддержке балансировки нагрузки, трассировки, проверки работоспособности и аутентификации gRPC хорошо подходит для микросервисов.
Как работает RPC
Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении и отправляет это сообщение на сервер. Получив сообщение, сервер десериализует его содержимое, выполняет запрошенную операцию и отправляет результат обратно клиенту. Стаб сервера и стаб клиента берут на себя сериализацию и десериализацию параметров.
Преимущества RPC
Простота и понятность взаимодействий. RPC использует GET для получения информации и POST для всего остального. Механика взаимодействия между сервером и клиентом сводится к вызову конечной точки и получению ответа.
Легкость добавления функций. Получив новое требование для API, мы можем легко добавить другую конечную точку, выполняющую это требование: 1) написать новую функцию и перебросить ее на конечную точку, и 2) теперь клиент может попасть в эту конечную точку и получить информацию, соответствующую заданному требованию.
Высокая производительность. Легкие полезные нагрузки легко распределяются по сети, обеспечивая высокую производительность, что важно для общих серверов и параллельных вычислений, выполняемых в сетях рабочих станций. RPC способен оптимизировать сетевой уровень и сделать его очень эффективным в ситуации, когда различные сервисы каждый день обмениваются тоннами сообщений.
Недостатки RPC
Плотная связь с базовой системой. Уровень абстракции API способствует его повторному использованию. Чем теснее связанность с базовой системой, тем хуже API подходит для других систем. Тесная связь RPC с базовой системой не позволяет создать уровень абстракции между функциями в системе и внешним API. Отсюда вытекают вопросы относительно безопасности, поскольку детали реализации базовой системы довольно легко просачиваются в API. Плотная связанность RPC создает трудности для требований к масштабируемости и слабо связанных команды. Таким образом, клиент либо беспокоится о возможных побочных эффектах вызова определенной конечной точки, либо пытается выяснить, какую конечную точку следует вызвать, потому что не понимает, по какому принципу сервер именует функции.
Низкая обнаруживаемость. В RPC нет никакого способа интроспектировать API или отправить запрос и начать понимать, какую функцию вызывать на основе его запросов.
Взрыв функций. Новые функции создавать очень легко. Поэтому вместо того, чтобы редактировать существующие, мы создаем новые, в результате чего получаем огромный список перекрывающихся функций, которые трудно понять.
Примеры использования RPC
Шаблон RPC получил первое применение примерно в 80-х годах, но это само по себе не делает его устаревшим. Крупные компании, такие как Google, Facebook (Apache Thrift) и Twitch (Twirp), используют внутри себя высокопроизводительные вариации RPC для чрезвычайно высокопроизводительного обмена сообщениями с низкими накладными расходами. Их массивные системы микросервисов требуют, чтобы внутренняя коммуникация была четкой и в то же время организованной в короткие сообщения.
API для команд. RPC — подходящий выбор для отправки команд в удаленную систему. Например, Slack API очень командно-ориентирован: зайти на канал, покинуть канал, отправить сообщение. Разработчики Slack API как раз и смоделировали его в стиле RPC, сделав его маленьким, компактным и простым в использовании.
Клиентские API для внутренних микросервисов. В случае прямой интеграции между единственным поставщиком и потребителем не хочется тратить много времени на передачу большого количества метаданных, как это делает REST API. gRPC и Twirp очень подходят для микросервисов благодаря высокой скорости передачи сообщений и их производительности. gRPC, с HTTP2 под капотом, способен оптимизировать сетевой уровень и повысить его эффективность при отправке с одного сервиса на другой тонн сообщений в день. Однако, если вы стремитесь не к высокой производительности сети, а к стабильному API-контакту между командами, публикующими очень отличающиеся друг от друга микросервисы, REST позаботится об этом лучше.
Протокол доступа к простым объектам (SOAP): предоставление данных в виде сервисов
SOAP — это высоко-стандартизированный протокол веб-коммуникаций, основанный на формате XML. Выпущенный Microsoft через год после XML-RPC, SOAP многое от него унаследовал. Когда на сцену вышел REST, они сначала применялись параллельно, но вскоре REST выиграл конкурс популярности.
Как работает SOAP
Формат XML тянет за собой много формальностей. В сочетании с массивной структурой сообщений он делает SOAP самым подробным стилем API.
SOAP-сообщение состоит из:
Логика SOAP API написана на языке описания веб-служб (WSDL). Этот язык описания API определяет конечные точки и описывает все процессы, которые могут быть выполнены. Это позволяет различным языкам программирования и IDE быстро налаживать коммуникацию.
SOAP поддерживает обмен сообщениями с отслеживанием состояния и без такового. В сценарии с отслеживанием состояния сервер хранит полученную информацию, которая может весить очень много. Но это оправдано для многосторонних операций и сложных транзакций.
Плюсы SOAP
Независимость от языка и платформы. Встроенная функциональность для создания веб-сервисов позволяет SOAP обрабатывать сообщения и делать ответы независимыми от языка и платформы.
Связанность с различными транспортными протоколами. SOAP гибок с точки зрения протоколов передачи и приспосабливается к более чем одному сценарию.
Встроенная обработка ошибок. Спецификация SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
Ряд расширений безопасности. Благодаря интеграции с протоколами WS-Security качество транзакций SOAP соответствует корпоративным стандартам. SOAP гарантирует конфиденциальность и целостность внутри транзакций, обеспечивая при этом шифрование на уровне сообщений.
Минусы SOAP
В наши дни многие разработчики содрогаются при мысли о необходимости интеграции SOAP API по нескольким причинам.
Только XML. SOAP-сообщения содержат много метаданных и поддерживают только подробные XML-структуры для запросов и ответов.
Тяжеловесность. Из-за большого размера XML-файлов SOAP-сервисы требуют большой пропускной способности.
Узкоспециализированные знания. Создание серверов SOAP API требует глубокого понимания всех задействованных протоколов и их строгих правил.
Утомительное обновление сообщений. Требуются дополнительные усилия для добавления или удаления свойств сообщения — жесткая схема SOAP замедляет принятие.
Сценарии применения SOAP
В настоящее время архитектура SOAP чаще всего применяется для интеграции внутри предприятий или с их доверенными партнерами.
Надежность передачи данных. Жесткая структура SOAP, а также возможности в плане безопасности и авторизации, делают его наиболее подходящим вариантом для обеспечения соответствия формальному программному контракту между API и клиентом при соблюдении юридического контракта между поставщиком API и потребителем API. Вот почему финансовые организации и другие корпоративные пользователи выбирают SOAP.
Передача состояния представления (REST): предоставление данных в качестве ресурсов
REST — самоописательный архитектурный стиль API, определяемый набором архитектурных ограничений и предназначенный для широкого внедрения многими потребителями API.
Наиболее распространенный сегодня стиль API был впервые описан в 2000 году Роем Филдингом в его докторской диссертации. REST делает доступными данные на стороне сервера, представляя их в простых форматах — чаще всего это JSON и XML.
Как работает REST
REST определен не так строго, как SOAP. RESTful-архитектура должна соответствовать шести архитектурным ограничениям:
На самом деле, некоторые сервисы соответствуют стандарту RESTful только в определенной степени. Они берут за основу стиль RPC, разбивают более крупные службы на ресурсы и эффективно используют инфраструктуру HTTP. Но ключевое здесь — гипермедиа, иначе HATEOAS, сокращенно от “Гипертекст как двигатель состояния приложения” (Hypertext As The Engine of Application State). По сути это означает, что с каждым ответом REST API предоставляет метаданные, связывающие всю информацию о применении API. Это то, что позволяет отделить клиента от сервера. В результате и поставщик API, и потребитель API могут развиваться независимо и это не затрудняет их коммуникацию.
“HATEOAS — ключевая особенность REST. Это действительно то, что делает REST самим собой. Поскольку большинство людей не используют HATEOAS, они пользуются HTTP RPC”, — такое радикальное мнение встретилось мне на Reddit. Действительно, HATEOAS — это самая зрелая версия REST. Однако этой цели трудно достичь. Для этого требуются гораздо более продвинутые и интеллектуальные клиенты API, чем те, которые обычно создаются и действуют в наши дни. Таким образом, даже действительно хорошие REST API сегодня не всегда соответствуют стандарту. Вот почему HATEOAS в основном служит ориентиром для долгосрочного развития дизайна RESTful API.
Между REST и RPC действительно может находиться серая зона, когда сервис реализует некоторые функции REST и некоторые RPC. REST основан на ресурсе (или существительном), а не на действии (или глаголе).
В REST все делается с помощью HTTP-методов, таких как GET, POST, PUT, DELETE, OPTIONS и, надеюсь, PATCH.
REST API: минимум, который нужно знать новичку
Что такое программный интерфейс приложения (API)
Перед тем, как начать разговор о REST API, давайте вспомним, что такое API и для чего он нужен. API расшифровывается как Application Program Interface — программный интерфейс приложения. Данное понятие применимо не только к веб-разработке, но и к любым программным продуктам вообще. Наушники, микроволновые печи, телевизоры, микропроцессоры — все они имеют свой API.
Предположим, мы имеем дело с двумя такими совершенно разными разработками, каждая из которых обладает своим собственным API. Эти системы должны как-то взаимодействовать между собой, но есть некоторая сложность — ведь каждая из систем разработана на своем языке, по своим стандартам, со своими драйверами, на своей операционной системе и так далее. Чтобы как-то привести эти системы к общему знаменателю и иметь возможность коммуникации, мы используем API как некие внешние рычаги, которые влияют на внутреннее состояние каждой из систем. По этому принципу работает огромное количество проектов.
REST API — частный случай API
Допустим, мы написали сайт на PHP (Python, Java — не принципиально). PHP генерирует контент на сервере и по сети нам отправляет обратно уже сгенерированный HTML, JavaScript и CSS. Создавая сайт на PHP, вы получили некую статику, напрямую связывая код PHP, стили, HTML. Он взаимодействует с базой данных и выводит данные в шаблон. Предположим, мы задались целью разработать мобильное приложение под данную систему. Мобильное приложение должно работать с той же базой данных и мы должны как-то присоединить его к уже существующей системе.
Раньше многие шли по такому пути — создавали API для системы «сайт плюс база данных», и мобильное приложение работало через API или непосредственно через сам сайт. Но поддерживать и расширять такую концепцию было неудобно, поэтому постепенно перешли к варианту, когда используется связка backend и frontend. Backend по-прежнему работает с базой данных, а frontend является вообще отдельным приложением, которое, грубо говоря, ничего не знает про backend. Frontend является абстрагированный клиентом и может быть написан на Angular, React, Vue или просто на JavaScript.
Если для сайта имеется мобильное приложение, оно также относится к разряду клиентов и общается с backend-частью посредством API. При такой схеме клиентов может быть сколько угодно — мобильный клиент для Android, приложение под iOS, десктопное приложение, админка сайта и т. д. Частным случаем такой организации является REST API (Representational State Transfer) — некий стандартизированный протокол, позволяющий перемещать state и обмениваться им по API. Впервые его описал в своей диссертации Рой Филдинг. В ней он предложил соединять разные части программы либо сервисы по HTTP.
Критерии RESTful-приложения
Rest — это обычный запрос клиент-сервер с использованием HTTP протокола. В роли клиента не обязательно выступает браузер, это может быть мобильное приложение, десктопное приложение или же другой веб-сайт. В качестве ответа сервер выдает не привычную html-страницу, а просто набор данных, оформленных в том или ином формате. Чаще всего это JSON или XML. Неразрывно с REST следует AJAX (Asynchronous Javascript and XML).
Речь идет об отправке с браузера асинхронных запросов к серверу с помощью JavaScript. XML в данном случае не актуален, а процесс асинхронного общения браузера и веб-сервера задается именно REST-правилами. Веб-сервисы, которые полностью соответствуют парадигме Representational State Transfer, обычно называются RESTful. Чтобы приложение было RESTful, оно должно удовлетворять следующим правилам:
SOAP API — стандарт–предшественник REST API
Хотя на REST API и накладываются эти ограничения, он считается более простым в использовании, чем предшествующий ему протокол SOAP (простой протокол доступа к объектам). Последний выдвигает определенные требования, такие как обмен сообщениями XML, а также встроенные средства безопасности и соответствия транзакциям, что делает его медленнее и тяжеловеснее.
При отправке запроса данных в SOAP API, данные могут обрабатываться через любой из протоколов прикладного уровня: HTTP (для веб-браузеров), SMTP (для электронной почты), TCP и прочие. SOAP использует HTTP как транспортный протокол, в то время как REST базируется на нем. Как только запрос получен, возвращаемые сообщения SOAP должны быть переданы в виде XML-документов — языка разметки, который может считываться как человеком, так и машиной. Завершенный запрос к SOAP API не кэшируется браузером, поэтому он не может быть доступен вторично без повторной отправки в API. На данный момент SOAP — это устаревший стандарт, тем не менее довольно часто используемый enterprise-системами.
Типы запросов
Благодаря тому, что REST API построен поверх HTTP, не важно на каком языке написан frontend (JavaScript или Swift) и backend (Python, Java, C# и пр.), все они смогут взаимодействовать с данным протоколом. Каждый ресурс в REST должен быть идентифицирован посредством стабильного идентификатора, который не меняется при изменении состояния ресурса. Идентификатором в REST является URI. При помощи URL REST API сервер понимает с какими объектами работает, какие объекты ему нужно получить и какие объекты следует удалить.
REST API активно использует методы HTTP протокола и его статуса. В нем присутствуют несколько основных типов запросов:
Если мы говорим о REST как о бизнес-логике, то у нас есть объект и мы передаем статус этого объекта. Например, у нас есть сайт пиццерии и новый заказ. Мы можем заказ создать, узнать о нем подробности, можем обновить его или удалить. И чаще всего для этого используется формат JSON.
Коды запросов
Структура запроса включает в себя маршрут запроса, тип метода, заголовки и тело сообщения. Каждый запрос REST API сопровождается цифровыми кодами. Такие коды называются HTTP-статусами. Они сообщают об успешности запроса.
Статусы разделены на пять групп по своему значению:
Например, редактирование записи на сервере может выполнено успешно (код 200), может быть заблокировано контролем безопасности (код 401 или 403), или не пройти вообще из-за ошибки сервера (код 500).
Чтобы работать с REST API сервисами можно использовать такие инструменты как Postman, SOAP UI (open source утилита по работе с сервисами) и Curl — утилита командной строки, присутствует почти на всех Linux-компьютерах.
Недостатки REST API
Минус этого архитектурного стиля состоит в том, что он завязан на HTTP. Спецификация HTML имеет ограничения и формы, отправляющие данные могут быть реализованы только через GET или POST. Поэтому для корректной работы с другими методами их приходится имитировать. Например, в Rack (механизм на базе которого Ruby взаимодействует с веб-сервером; с использованием Rack сделаны Rails, Merb и прочие Ruby-фреймворки) в форму можно прописать hidden-поле с именем “_method”, а в качестве значения указать имя метода (скажем, «PUT») — при этом будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
Заключение
Теперь вы знаете, что такое REST API и где он применяется. Если говорить понятными словами — это возможность сервера давать доступ клиенту к своим ресурсам. Главный плюс REST API — его простота. Обращение REST API мало чем отличается от обычного запроса к веб-сайту (с небольшим расширением и описанием набора правил, как эти запросы будет происходить).
Недостатком REST API является то, что он опирается на спецификацию HTTP-протокола. Сам по себе REST API не является стандартом, это архитектурный подход. Из этого следует, что он может сильно отличаться у разных компаний. REST удобно использовать в простых случаях и когда важна скорость работы — при работе с мобильным устройством, с JavaScript. В сложных случаях, когда критична поддержка валидации, транзакции — используется SOAP. Помимо REST API имеются и иные способы создания API-систем, такие как JSON-RPC, XML-RPC и GraphQL. Однако на данный момент архитектурный стиль REST API остается самым популярным.
Детальное описание всех кодов REST-запросов (справочник) можно найти здесь — https://restapitutorial.ru/httpstatuscodes.html
Подробнее о REST-проектах, построенных с применением данного архитектурного стиля, а также их отличиях от SOAP сервисов можно узнать из видео ниже: