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

Но почему нет четких спецификаций для REST? Потому что REST на самом деле представляет собой архитектурный набор руководящих принципов, принципов и философий из диссертации Роя Филдинга. В отличие от JSON API или HAL, это не сводится к набору шагов или правил, и нам остается интерпретировать его спецификацию, а разные люди интерпретируют ее по-разному.

На одном из дискуссионных онлайн-форумов Рой Филдинг записал свое недовольство службой, которая утверждает, что является RESTful, но эта служба представляет собой простой интерфейс на основе HTTP. Он сказал, что сервис не соответствует всем необходимым ограничениям архитектуры REST. Он даже сказал, что если Engine of Application State (и, следовательно, API) не управляется гипертекстом, то он не может быть RESTful и не может быть REST API.

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

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

Концепции REST

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

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

Концепции REST (Representational State Transfer) были представлены Роем Филдингом в качестве докторской диссертации. Как основатель стиля REST, он применяет следующие 6 ограничений REST как обязательные для того, чтобы любой веб-сервис был квалифицирован как RESTful. Эти обязательные ограничения заключаются в следующем.

Ограничения архитектурного стиля REST

Ниже приведены ограничения REST:

  • Клиент-сервер
  • Безгражданство
  • Кэшируемый
  • Единый интерфейс
  • Многоуровневые системы
  • Код по запросу (необязательно)

Клиент-сервер

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

Во-первых, количество клиентов, которые может обслуживать один сервер, не ограничено. Также не обязательно, чтобы клиент и сервер находились в разных системах. Оба могут находиться в одной и той же системе в зависимости от аппаратной конфигурации системы и типа функций или услуг, предоставляемых сервером.

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

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

В дополнение к разделению ответственности, клиент-серверная архитектура будет иметь следующие преимущества.

  • Улучшить переносимость пользовательского интерфейса
  • Повышение масштабируемости за счет упрощения реализации сервера
  • Разработка с использованием автономного, независимого и тестируемого компонента

Безгражданство

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

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

  • Клиент несет полную ответственность за хранение и обработку всех состояний приложения и соответствующей информации на стороне клиента.
  • Клиент несет ответственность за отправку любой информации о состоянии на сервер всякий раз, когда это необходимо.
  • Нет привязки сеанса или сходства сеанса на сервере для вызывающего запроса (клиента).
  • Сервер также должен включать любую необходимую информацию, которая может понадобиться клиенту для создания состояния на своей стороне.
  • Взаимодействия HTTP включают два вида состояний: состояние приложения и состояние ресурса, и безгражданство применяется к обоим. Давайте посмотрим, как ограничение отсутствия состояния обрабатывается в каждом состоянии:
  • Состояние приложения: данные, которые хранятся на стороне сервера и помогают идентифицировать входящий запрос клиента, используя сведения о предыдущем взаимодействии с текущей контекстной информацией.
  • Состояние ресурса: это называется представлением ресурса и не зависит от клиента (клиенту не нужно знать это состояние, если только оно не доступно, так как требуется ответ), и это текущее состояние сервера в любой момент времени

Преимущества и недостатки безгражданства

Это некоторые преимущества

  • Поскольку серверу не нужно управлять каким-либо сеансом, возможно развертывание служб на любом количестве серверов, поэтому масштабируемость никогда не будет проблемой.
  • Отсутствие состояний означает меньшую сложность; нет логики синхронизации сеанса (состояния) для обработки на стороне сервера
  • Поскольку вызовы службы (запросы) могут кэшироваться базовым приложением, ограничение отсутствия состояния снижает время отклика сервера, то есть повышает производительность в отношении времени отклика.
  • Бесшовная интеграция/реализация с протоколами HTTP возможна, поскольку HTTP сам по себе является протоколом без сохранения состояния.
  • Улучшает видимость, поскольку каждый запрос является отдельным ресурсом и может рассматриваться как независимый запрос.
  • Повышает надежность, поскольку может восстанавливаться после частичных сбоев.

Это некоторые недостатки

  • Увеличьте накладные расходы на взаимодействие
  • Каждый запрос веб-сервисов должен получать дополнительную информацию, чтобы ее можно было проанализировать (интерпретировать), чтобы сервер понял состояние клиента из входящего запроса и при необходимости позаботился о сеансах клиент/сервер.

Кэшируемый

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

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

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

Преимущества кэширования

Кэширование имеет множество преимуществ, таких как:

  • Уменьшенная пропускная способность
  • Уменьшенная задержка (более быстрое время отклика)
  • Снижена нагрузка на сервер
  • Скрыть сбои в сети и отправить клиенту ответ\

Единый интерфейс

Из всех ограничений REST это наиболее широко известное и иногда даже ошибочно воспринимаемое как RESTful. Я полагаю, что большинство из вас знакомы с этим, да, это ограничение касается использования методов HTTP, таких как GET, POST, PUT, DELETE и т. д. Однако унифицированный интерфейс — это не только это. Есть четыре важных руководящих принципа, предложенных Филдингом, которые составляют необходимые ограничения для удовлетворения унифицированного интерфейса, и они заключаются в следующем:

  • Идентификация ресурсов
  • Манипулирование ресурсами
  • Самоописательные сообщения
  • Гипермедиа как механизм состояния приложения (HATEOAS)

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

Идентификация ресурсов

В веб-приложении универсальный идентификатор ресурса (URI) может представлять именованный объект. Сущность может быть идентифицирована и назначена в качестве ресурса путем явной ссылки на нее. Например, сущность Project, принадлежащая сущности Organisation, может быть идентифицирована в следующем URI https://api.github.com/orgs/ORG/projects. В ограничениях REST используемые URI описываются следующим образом:

  • Семантическое сопоставление URI с ресурсом не должно меняться. Например, https://api.twitter.com/1.1/statuses/retweets/:id в Твиттере в качестве URI никогда не может измениться и всегда будет представлять ресурсы ретвитов, даже если содержание или значения будут продолжать улучшаться, согласно последние обновления.
  • Идентификация ресурса не зависит от его значений, поэтому два ресурса могут указывать на одни и те же данные в какой-то момент, но они не являются одним и тем же ресурсом.
  • URI дают такие преимущества, как единственный способ доступа к ресурсу, динамические типы мультимедиа для ответов ресурсов (обслуживание типа мультимедиа во время его запроса) с помощью заголовков Accept и клиенты, получающие доступ к этим ресурсам. динамическим ресурсам не нужно изменять какие-либо идентификаторы, если в типе содержимого ответа внесены какие-либо изменения.

Манипулирование ресурсами

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

Предыдущая концепция заключается в том, чтобы позволить ресурсу быть представленным различными способами без изменения его идентификаторов. Это возможно, если заголовок HTTP (Accept) передается серверу клиентами в каждом запросе. Ресурсы обновляются или добавляются путем отправки представлений от клиента приложением RESTful. Ниже приведен пример формата представления от Postman.

Таким образом, отделение представления ресурса от URI является одним из важнейших аспектов REST.

Самоописательные сообщения

Запрос клиента и ответ сервера являются сообщениями, и эти сообщения не должны содержать сведений о состоянии и быть информативными. Но что имеется в виду под выражением «без гражданства» и «самописательным»?

Желаемое состояние ресурса может быть представлено в сообщении запроса клиента. И текущее состояние ресурса может быть воплощено в ответном сообщении, которое возвращается с сервера. Например, клиент редактора вики-страниц может использовать сообщение запроса для передачи представления, которое предлагает обновление страницы (новое состояние) для веб-страницы, управляемой сервером (ресурс).

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

Таким образом, самоописательное сообщение в стиле REST связано с тем, что не поддерживается состояние между клиентом и сервером, и каждый запрос должен нести достаточно информации о себе или объясняться явными состояниями.

Гипермедиа как механизм состояния приложения (HATEOAS)

Гипермедиа как механизм состояния приложения (HATEOAS) — один из наиболее важных аспектов ограничения REST. Без обращения к этому сервисы не могут называться RESTful-сервисами. Но что такое HATEOAS в первую очередь? Вот основная идея.

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

При всем сказанном основная идея HATEOAS заключается в том, чтобы клиенты использовали гипермедиа-ссылки, предоставленные в ответ. И позволяет клиенту динамически переходить к соответствующим ресурсам, проходя гипермедиа-ссылки. Отсутствие или наличие ссылки на странице является важной частью текущего состояния ресурса и поэтому важно для RESTful API.

Пожалуйста, взгляните на следующий пример.

В предыдущем примере ответ справа снабжен гиперссылками для «изменения» и «удаления» ресурса. Клиент может использовать эти ссылки для обновления или удаления указанного ресурса. И через эти гиперссылки сервер управляет состоянием приложения, а не наоборот.

Многоуровневые системы

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

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

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

В то время как многоуровневая система приводит к дополнительным задержкам и накладным расходам, существуют компромиссы, которые являются преимуществами многоуровневых систем, таких как:

  • Инкапсулирует устаревшие сервисы
  • Представляет посредников
  • Ограничение сложности системы
  • Улучшает масштабируемость

Код по запросу (необязательно)

Код по запросу классифицируется как необязательный, что означает, что архитектуры, которые не используют эту функцию, могут по-прежнему считаться RESTful.

В распределенных вычислениях код по запросу (COD) — это любая технология, которая позволяет серверу отправлять программный код клиентам для выполнения на клиентском компьютере по запросу от клиентского программного обеспечения.

Приложения RESTful вполне могут использовать клиентов, поддерживающих COD. Например, веб-браузеры могут позволять серверам возвращать сценарии или ссылки, которые могут выполняться на стороне клиента. Такое дополнительное выполнение кода помогает расширить возможности клиента, не требуя от пользователя установки нового клиентского программного обеспечения.

Заключительная мысль

Эй, вы дошли до конца этой длинной статьи. Спасибо, что дочитали до этого момента. Как вы читали выше, это шесть ограничений REST и то, как, по мнению Роя, они определяют архитектурный стиль как RESTful.

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

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

Архитектурный стиль REST предоставляет набор свойств, которые помогают установить цели проектирования, встроенные в приложение ограничений REST. Эти свойства следующие:

  • Представление
  • Масштабируемость
  • Простота
  • Модифицируемость
  • Видимость
  • Портативность
  • Надежность
  • Тестируемость

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

Надеюсь, вам понравилась эта статья и вы нашли эту историю полезной, увидимся в следующей истории ✋