Что такое ОТДЫХ? Фактический стандарт веб-архитектуры.

REST, или передача репрезентативного состояния, — это повсеместный архитектурный стиль, который отвечает на ключевой вопрос: как будут взаимодействовать веб-серверы и клиенты? Из всех аббревиатур, встречающихся в мире разработки программного обеспечения, REST является одним из наиболее распространенных. Это также одно из наиболее часто неправильно понимаемых понятий. Эта статья предлагает краткое руководство по REST как в теории, так и на практике. Другими словами, мы рассмотрим как теорию REST, так и то, как она на самом деле реализуется, в основном в форме RESTful API.

ОТДЫХ в теории

Создание программного обеспечения для распространения в Интернете влечет за собой определенную степень сложности. Стек TCP/IP и HTTP дает нам базовый механизм обмена данными по сети, но на этом протоколы заканчиваются. Разработчикам программного обеспечения пришлось разработать собственные подходы более высокого уровня для организации упаковки и распределения ресурсов через веб-приложения.

Введение в REST Рой Филдинг начал с подробного описания сильных и слабых сторон различных веб-архитектур на рубеже веков. Он пришел к выводу, что сложностью сетевых систем трудно управлять и что разработчикам нужен способ сохранить такие полезные качества, как масштабируемость, надежность и производительность, не жертвуя при этом простотой.

Затем Филдинг предложил REST в качестве архитектурного решения сложности распространения программного обеспечения через Интернет. Краткое изложение его предложения могло бы быть таким: компоненты должны передавать свое внутреннее состояние в стандартном, независимом от реализации формате.. Иными словами, веб-архитектура должна состоять из отдельных компонентов, которые обмениваются данными по стандартному протоколу. Это был просто хороший дизайн, хотя и применимый к большому проблемному пространству. Но Филдинг имел в виду нечто более конкретное:

Название «Передача репрезентативного состояния» призвано вызвать представление о том, как ведет себя хорошо спроектированное веб-приложение: сеть веб-страниц (виртуальный конечный автомат), в которой пользователь перемещается по приложению, выбирая ссылки (переходы состояний). , в результате чего следующая страница (представляющая следующее состояние приложения) передается пользователю и отображается для его использования.

Вы заметите, что в этом описании выделяются веб-страницы и ссылки. Первоначально REST относился к гипермедиа (особенно HTML) и гиперссылкам. По сути, веб-служба размещает ресурсы по различным URL-адресам и URI. Когда пользователь вызывает ресурс, служба отвечает HTML-страницей. Страница содержит ссылки, которые можно использовать для перехода к другим ресурсам, поэтому процесс продолжается. Это видение поддерживает многие цели хорошего проектирования программного обеспечения: унифицированные интерфейсы, компоненты без сохранения состояния, кэшируемые ресурсы и сервисы, которые могут быть составными или многоуровневыми.

REST на практике: RESTful API

В наши дни наиболее распространенный подход к REST не работает так, как он был задуман изначально. Вместо этого разработчики обычно используют HTTP API и JSON для предоставления данных приложениям в Интернете. Вот почему вы часто будете слышать так называемую REST-архитектуру, описываемую как RESTful– что-то похожее на REST. (Возможно, REST-иш более точен.)

В стиле RESTful клиент запрашивает ресурс, используя URL-адрес в традиционном формате (RESTful API), и получает обратно ответ JSON в традиционном формате, который описывает ресурс с использованием пар ключ/значение.

Обычные ответы URL и JSON являются отличительными характеристиками современных веб-приложений RESTful. В этом стиле URL-путь описывает, где находится ресурс, а команда HTTP описывает, как им манипулировать. Например, если у вас есть API, содержащий данные о музыке, у вас может быть URL-адрес конечной точки, например musicservice/albums/1234, где 1234 — идентификатор данного актива. Если вы выдадите GET запросите эту конечную точку, вы получите обратно документ JSON для этого актива, примерно так:

Листинг 1. Простой RESTful-сервис

Response:
{
  id: 1234,
  name: “Abbey Road”,
  band: “The Beatles”,
  year: 1969,
  best_song: “Come Together”
}

В листинге 1 вы видите, что конечная точка отвечает данными, описывающими актив. Это соответствует требованию о том, чтобы служба не раскрывала ничего о реализации. Остальные глаголы позволяют удалить ресурс (HTTP DELETE), измените его (HTTP PUT) или создайте новый (HTTP POST).

Структура API не является жесткой. Главное правило заключается в том, что GET запросы не должны ничего менять (другими словами, GET является идемпотент). Часто GET запрос к musicservice/albums конечная точка вернет список альбомов. Конечная точка также будет поддерживать параметры фильтра и/или запроса как часть URL-адреса, например:

musicservice/albums?band_name=”pink_floyd”&years=”1973-1980”&sort=alpha

По мере усложнения API представление ресурсов становится менее последовательным. Допустим, наш API MusicService поддерживает маркировку альбомов по стилю или жанру. Вы можете связать тег с альбомом или альбом с тегом. Во многих случаях подход в RESTful API сводится к стилю и предпочтениям. Самое важное правило: быть как можно более последовательным. Вы хотите, чтобы синтаксис URL-адресов был единообразным, чтобы кому-то, кто пишет код для API, было легко выполнять свою задачу.

Другие соглашения включают использование команды POST HTTP для добавления нового ресурса. В этом случае URL-адрес обычно принимает объект JSON со свойствами нового объекта. Для обновления обычно используется PUT. Здесь URL-адрес обычно содержит идентификатор (/musicservice/albums/1234), а при загрузке — JSON с новыми данными.

Когда вы видите обсуждение REST в наши дни, оно обычно имеет в виду такой тип RESTful дизайна. Клиенты написаны на JavaScript с использованием одной из многих доступных платформ. Запросы в стиле Ajax часто используются для детального взаимодействия в одностраничных приложениях. Сервисы (вплоть до микросервисов) используют RESTful API, поскольку они позволяют использовать все виды технических стеков, которые приняли соглашения REST для сокрытия своих базовых реализаций. Службы, написанные в этом стиле, могут взаимодействовать друг с другом для согласованного и совместимого выполнения запросов.

REST против SOAP

Теоретически REST — это своего рода самоописающаяся архитектура сервиса, в которой клиенты понимают, каковы стандарты, а сервис выдает данные, соответствующие этим стандартам. Клиент может более или менее действовать, ничего не зная о структуре сервиса. На другом конце спектра находится стиль отношений клиент-сервис, называемый удаленным вызовом процедур или RPC. В этой модели клиент и сервер заранее создают формальный контракт, который определяет точный характер их взаимодействия. Затем они взаимодействуют таким же образом, как вызовы процедур в локальном коде. RPC сопоставляет вызовы функций обычного кода с сетевыми вызовами.

RPC имеет некоторые преимущества, заключающиеся в том, что он более строгий и позволяет планировать и четко определять услуги и клиентов. Недостатком RPC является его жесткость. Всякий раз, когда меняется клиент или сервер, другой тоже должен измениться, как и механизм, определяющий контракт.

RPC и SOAP

Самым известным примером RPC, вероятно, является SOAP (простой протокол доступа к объектам). В этой системе клиенты и серверы используют определения XML для описания своих контрактов. SOAP был важной частью движения SOA (сервис-ориентированная архитектура) на рубеже веков. В этой модели сервисы предоставляют определения сервисов, и клиенты могут анализировать их, чтобы обнаружить возможности. Однако эта идея не сработала, главным образом из-за сложности. SOA и SOAP добавили слишком много накладных расходов к и без того сложной работе, которую приходилось выполнять разработчикам. (Обзор более современного подхода к RPC см. в разделе «Введение в gRPC: альтернатива REST».)

Теоретически REST обходится без уникальных контрактов между клиентами и серверами, позволяя службе отправлять данные в формате, который описывает саму себя. Это обеспечивает большую гибкость при сохранении возможностей (гениальность статьи Филдинга).

ОТДЫХ в том виде, в котором он практикуется, является скорее естественной промежуточной точкой. Там, где RPC и SOA используют формальные контракты клиент-сервер, REST и REST-подобный JSON этого не делают. Там, где REST отделяет клиентов и серверов (с ограниченным предварительным знанием службы на клиенте), REST-подобные клиенты подключаются к серверу (они имеют предварительную информацию об услуге). На рисунке 1 показана разница между двумя архитектурами.

ИДГ

Когда мы говорим, что клиентам REST не хватает предварительных знаний об услуге, мы имеем в виду, что они не знают специфики. Они могут знать и, вероятно, знают больше об используемых стандартных структурах и предположениях. Другими словами, настоящий REST-клиент должен быть более искушен в стандартах, чтобы быть менее искушенным в специфике.

REST-подобные службы (то есть службы JSON-URL) фактически максимизируют скорость разработки. Поэтому неудивительно, что эта модель нашла наибольшее применение в реальных условиях.

А как насчет ХАТЕОАС?

Недостатком REST-подобного подхода является его склонность к сложности. В этом он расходится с видением REST Роя Филдинга. Сложность проектирования RESTful наиболее очевидно проявляется в сложности современных веб-клиентов, которые должны иметь возможность получать JSON и динамически преобразовывать его в интерактивные пользовательские интерфейсы.

Проблема здесь в том, что большинство разработчиков, реализующих REST как архитектурный стиль, отказались от одного из его первоначальных столпов — принципа HATEOAS. Эта странно непривлекательная аббревиатура означает Гипермедиа как двигатель состояния приложения. По сути, это означает, что мы должны выпускать гипермедиа только из сервисов — идея, которая прямо противоположна выпуску JSON в качестве средства распространения. Филдинг называет этот принцип ограничение гипермедиаи он открыто заявил о широко распространенном нарушении:

REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу контролировать свое собственное пространство имен. Вместо этого позвольте серверам инструктировать клиентов о том, как создавать соответствующие URI, например, это делается в формах HTML и шаблонах URI, определяя эти инструкции в типах мультимедиа и отношениях ссылок. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling.]

Очевидно, что большинство API-интерфейсов RESTful игнорируют этот важный аспект стиля REST, где клиенты должны просто следовать выводам сервисов, включая все данные, необходимые для взаимодействия с сервисами. Сущность гипермедиа заключается в том, что она описывает как активы, так и и как в них ориентироваться. (Карсон Гросс, создатель HTMX, недавно затронул этот вопрос в своем блоге «Как REST стал означать противоположность REST?». Это стоит прочитать.)

Заключение

Критика стиля RESTful по сравнению с первоначально задуманным дизайном REST обоснована. Поддерживать службы JSON/HTTP сложно, и REST в том виде, в каком он задуман, может вселять некоторую надежду на улучшения. В то же время в реальной жизни по-прежнему используются ответы JSON, основанные на структурах URL-адресов, подобных RPC. Преимуществом этого стиля является его широкое использование, широкая реализация и легко понимаемая семантика.

Сегодня каждый работающий веб-разработчик должен понимать как основные принципы REST (теория), так и то, как они широко применяются в приложениях и интерфейсах RESTful (практика). Оба варианта заслуживают рассмотрения, поскольку мы продолжаем строить этот интернет-самолет, пока летаем на нем.