Понимаем REST. Часть 1


Содержание:

  • Часть 1 - Понимаем REST. Часть 1

Так как изначально я подразумеваю то что этот пост может быть полезен не только тем кто уже работал с REST но и новичкам, я должен пояснить немного о базовых моментах.

Введение в REST

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

Прежде всего что нужно знать о REST это то что он не является стандартом. REST это архитектурный стиль, которому рекомендуется придерживаться чтобы достичь Дзен. Именно о достижении Дзен-а мы и поговорим ниже.

Ну и пояснение с википедии:

REST (REpresentational State Transfer) - это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web.

Ограничения REST

REST можно охарактеризовать 6ю ограничениями, которые говорят как построен архитектурный стиль REST и чего стоит придерживаться.

1. Uniform Interface

Uniform Interface (Единый интерфейс) - определяет интерфейс между клиентами и серверами. Упрощает и отделяет архитектуру, которая позволяет каждой части развиваться самостоятельно.

К единому интерфейсу относится HATEOAS (Hypermedia as the Engine of Application State) о котором более обширно речь пойдет в следующей статье.

Клиенты предоставляют статус через содержимое body, параметры строки запроса, заголовки запросов и запрашиваемый URI. Например:

GET localhost:8080/greeting?name=World

HATEOS также означает, что, в случае необходимости ссылки содержатся в теле ответа для поддержки URI извлечения самого объекта или запрошенных объектов.

{
  "content":"Hello, World!",
  "_links":{
    "self":{
      "href":"localhost:8080/greeting?name=World"
    }
  }
}

Единый интерфейс так же означает, что любой REST сервис должен обеспечивать его фундаментальный дизайн.

2. Stateless

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

Также ваши REST сервисы не должны хранить состояние. REST сервис должен понимать что необходимо выполнить на основе HTTP запроса, его метода, параметров и заголовков. Каждый URI ресурс несет за собой обязанность выполнения какой-то логики, и в результате вернуть результат выполнения клиенту.

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

URI (Uniform Resource Identifier) - универсальный идентификатор ресурса.

После того, как сервер завершит обработку, состояние или его часть отдается обратно клиенту через заголовки, статус и тело ответа.

3. Cacheable

Cacheable (Кеширование ответа) - для предотвращения повторных вызовов следует предоставить кешируемость вашему URI таким образом чтобы один и тот же URI с одинаковыми параметрами не инициировал выполнение логики вашего сервиса дважды.

Хорошо спроектированное кэширование частично или полностью устраняет некоторые клиент-серверные взаимодействия, способствуя дальнейшей масштабируемости и производительности.

Более детальный пример кеширования тут.

4. Client–Server

Client–Server (Клиент-сервер) - серверы и клиенты могут быть заменяемы и разрабатываться независимо, пока интерфейс не изменяется.

Серверы не связаны с интерфейсом пользователя или состоянием, так что серверы могут быть проще, и масштабируемы.

REST Client–Server

5. Layered system

Layered system (Многоуровневая система) - обеспечивает независимость общения клиента напрямую с сервером, посредством предоставления промежуточного слоя посредника.

Промежуточный сервер может улучшить масштабируемость системы, обеспечивая балансировку нагрузки и предоставляя общий кэш. Слои также могут отвечать за политику безопасности.

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

6. Code on demand (optional)

Code on demand (Код по требованию) - серверы могут временно расширять или кастомизировать функционал клиента, передавая ему логику, которую он может исполнять.

Например, это может быть клиентский скрипты на Javascript который дополнит заранее не известную логику клиента.

Важно!

Также хочу обратить ваше внимание что Code on demand является optional то есть необязательным ограничением, которое можно не соблюдать при построении RESTful архитектуры.

Заключениие

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

Рекомендуемое:

SOLID простым языком

Тут я попытаюсь максимально просто и в тот же момент максимально информативно вам пояснить, что же такое SOLID и почему вам его нужно знать.