Возможно, вы видели, как термин REST использовался в последнее время, и вам было немного любопытно, что это такое. Если это так, или вы немного знаете об этом, но никогда не использовали его, эта статья для вас. Сегодня я собираюсь дать небольшой обзор того, что такое REST-сервисы и почему это здорово.
Так долго RPC, Привет, ОТДЫХ
Если вы были в сетевой игре некоторое время, вы можете вспомнить, когда RPC захватил сеть около 10 лет назад. Я сам помню, что это была одна из самых захватывающих вещей своего времени. Несмотря на то, что модель существует с 80-х годов, она начала появляться в сети в начале 2000-х годов, и в то время RPC был отличным решением. На самом деле он все еще используется повсеместно.
RPC расшифровывается как Удаленный вызов процедур, и это способ выполнить метод в отдельном адресном пространстве, например на сервере, и при необходимости использовать вывод. Вот примерная диаграмма того, как это выглядит:
Как вы можете видеть, веб-сервер по адресу www.yoursite.com отправляет и извлекает информацию с других серверов и использует эти данные для сборки веб-страницы. Вызовы RPC могут предоставлять услуги практически для всего: от протоколов обмена сообщениями до биржевых котировок, отчетов о погоде и т. Д. WordPress широко использует его для проверки связи с другими блогами и множеством служб связи.
XML RPC и SOAP
Как правило, есть два способа выполнения вызовов RPC, с XML и SOAP. У каждого есть свои преимущества, но когда я создавал много такого, я предпочитал методы XML-RPC, которые представляли собой вызов RPC серверу, который возвращал XML. Это очень просто и понятно, и не требует много церемоний.
SOAP (Simple Object Access Protocol) также использует XML для обмена сообщениями, но предоставляет расширяемую и мощную систему обмена сообщениями. Требуется немного больше работы в обмен на более мощные функции.
Ни одна из этих систем не была изначально плохой и не обеспечивала отличных решений для времени. Это все еще распространено во всем Интернете и преуспевает. В 2008 году Леонард Ричардсон представил модель, которая сегодня гораздо полезнее.
Если вам нужно более подробное объяснение, ознакомьтесь с этой статьей Microsoft TechNet по RPC.
Основные принципы ОТДЫХА
Короче говоря, Отдых — это набор принципов, которых нужно придерживаться при общении от точки к точке. Вот некоторые из этих рекомендаций
- Сделки с объектами (ресурсами), которые имеют идентификаторы
- Связывает серверы вместе
- Обеспечивает интерфейс между пробелами
- Использует стандартные методы
- без гражданства
Вот некоторые из основных вещей, которые делают услугу ОТЛИЧНОЙ по своей природе. Одним из важных принципов является то, что они должны быть объектами с идентификатором. Эти идентификаторы будут использоваться в URI для определения того, какой ресурс мы читаем или изменяем.
http://www.yoursite.com/api/products/1234
Далее мы рассмотрим модель для определения, является ли API «RESTful» и какому уровню он соответствует.
Модель зрелости REST
Ричардсон создал модель REST Maturity, которая определяет, является ли API «полностью RESTful». Большинство нет, и не обязательно должно быть. Но вот краткое изложение:
Уровень 0 — XML-RPC / SOAP
- Один URI
- Один метод HTTP
Уровень 0 — это очень базовая модель, в которой вы просто отправили RPI (удаленный вызов процедур) на веб-сайт, и он возвращает некоторые данные. Он может быть в формате XML, JSON или в любом формате с парами ключ-значение.
Уровень 1 — Добавить URI
- Многие URI / ресурсы
- Один метод HTTP
Уровень 1 похож, за исключением того, что сейчас используется несколько ресурсов:
http://www.yoursite.com/api/products/1234
http://www.yoursite.com/api/customers/0037
Уровень 2 — Добавить HTTP
- Многие URI / ресурсы
- Использование HTTP-глаголов
На уровне 2 мы добавляем HTTP-глаголы: GET, POST, PUT, DELETE. Есть и другие, но эти четыре я опишу позже.
Уровень 3 — Добавить HATEOAS
- Многие URI / ресурсы
- Использование глаголов HTTP
- гипермедиа
На этом уровне мы добавляем HATEOAS: гипертекст как двигатель состояния приложения. Это то, как мы отправляем объекты, а также некоторые инструкции в ответе, описывающие, что мы можем делать дальше. Например, он может вернуть что-то вроде этого:
<?xml version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">100.00</balance>
<link rel="deposit" href="/account/12345/deposit" />
<link rel="withdraw" href="/account/12345/withdraw" />
<link rel="transfer" href="/account/12345/transfer" />
<link rel="close" href="/account/12345/close" />
</account>(из Википедии)
Эти средства управления гипермедиа означают, что клиенту REST не нужно знать, как использовать службу, и вместо этого он может руководствоваться ответами. Это то, что считается «полностью RESTful» сервисом.
HTTP-глаголы
Глаголы HTTP — это стандартный интерфейс для связи через службу REST. Существует глагол «createobject», или «modifyobject», поэтому эти действия выполняются с помощью набора глаголов:
- ПОЛУЧИТЬ
- ПОСЛЕ
- ПОЛОЖИТЬ
- УДАЛИТЬ
Я постараюсь объяснить это как можно проще. Здесь мы работаем с «ресурсами», которые похожи на записи в SQL (или могут напрямую соотноситься с записями).
GET — получает список ресурсов и не изменяет их. Эквивалент SQL SELECT
POST — обычно используется для создания нового ресурса. Эквивалент SQL INSERT
PUT — заменяет ресурс обновленной информацией. Эквивалентно SQL UPDATE
УДАЛИТЬ — Удаляет ресурс. Эквивалент SQL DELETE
Все это делается через HTTP. Используется больше HTTP-глаголов, но я упоминаю их, поскольку они наиболее часто используются для REST. Фактически, некоторые инженеры используют только GET и POST для всех операций. Теоретически вы можете делать все с помощью GET, если вы перегружаете запросы в URI, но обычно рекомендуется использовать эти глаголы для ваших действий.
Все нуждается в удостоверении личности
Все эти ресурсы должны иметь идентификатор. Это особенно верно для PUT и DELETE, так как нам нужно знать, какие ресурсы нужно изменить за кулисами. Идентификатор обычно передается в URI:
http://www.yoursite.com/api/customers/0037
Если мы отправим PUT на этот URI, он обновит ресурс клиента с идентификатором 0037. Если мы отправим DELETE на этот URI, он удалит его.
Глаголы, которые должны быть идемпотентными
Теоретически глаголы GET, PUT и DELETE должны быть идемпотентными, то есть вы можете вызывать их через овер, без каких-либо дополнительных побочных эффектов. Например, вы должны иметь возможность отправлять удаление на URI снова и снова, не нарушая систему. Даже если ресурс был удален, вы должны отправить код обратно, но не выдавать исключение или сбой.
Часто при разработке интерфейсов REST я отправляю 200 (ОК) при удалении ресурса. Затем при последующих удалениях я отправлю 204 или 404, чтобы звонящий знал, что ресурс больше не присутствует. Однако я не делаю это с PUT. Даже если вызывающий отправит PUT с одной и той же информацией снова и снова, он получит один и тот же ответ, потому что я не собираюсь проверять, действительно ли представленные данные отличаются. Вместо этого я просто буду слепо обновлять ресурс любой отправленной информацией. Нас не волнует, действительно ли данные отличаются, и мы не хотим тратить их на проверку циклов, если только мы не проводим какую-либо форму аудита.
Пример REST API
Вот пример простого REST API, использующего информацию, о которой мы узнали выше. Мы хотим создать API для изменения информации о наших клиентах.
Как вы можете видеть, иногда URI один и тот же, но отправляемый глагол отличается. Это важно знать при создании приложения, потому что смешивание глаголов может дать неожиданные результаты. Вы можете обновить ресурс и удалить его.
Связь между конечными точками
Есть несколько способов общения через REST, и нет правильного ответа. Наиболее распространенными способами являются XML и JSON. Вот легкое сравнение между ними.
XML:
Плюсы:
- Обобщенная разметка, так что вы можете создавать несколько форматов и стилей для пользовательских целей.
- Вы можете определить схему для пользовательских типов данных и выполнить проверку структуры.
- может использовать XPATH для извлечения информации намного проще, чем JSON
Минусы:
- Гораздо более многословно, чем JSON, больше данных передается и может быть медленнее
JSON
Плюсы:
- Простая интеграция с JavaScript (который обычно используется для взаимодействия со службами REST)
- Простой, понятный синтаксис
- Меньше накладных расходов, меньших размеров и лучшей производительности
Минусы:
- Менее мощный и гибкий, особенно с разными типами данных
Резюме
Я надеюсь, что это дало хороший обзор того, что такое REST-сервисы и как они структурированы. Тенденции в области веб-технологий отошли от обычных веб-сервисов промежуточного программного обеспечения, которые генерируют HTML для браузеров, и сегодня люди получают доступ в Интернет с различных устройств, включая телефоны, планшеты и часы. REST хорошо подходит для этого, поскольку предоставляет общий интерфейс для ваших данных, предоставляя вам свободу использования этих данных на различных платформах.
Одна и та же служба REST может обеспечить работу веб-страницы, мобильного приложения или всего, что вы можете себе представить. Вы можете легко синхронизировать веб-страницу и мобильное устройство (подумайте о Spotify). REST — это будущее Интернета и то, что вы должны использовать для своего следующего проекта, если вы еще этого не сделали.
Я хотел бы поблагодарить POSTman, который является отличным интерфейсом для тестирования служб REST. Вы можете использовать его при разработке REST-бэкэнда или внешнего приложения. Это необходимо.