В данной статье рассматриваются следующие вопросы:

• Что такое ОТДЫХ
• Какие ограничения содержит REST
• Что такое REST
• В чем сложность чистого RESTful API

Если вы ищете «что такое REST», в большинстве случаев вы видите в основном RESTful!

Этот контент в основном говорит:

• Как должен быть написан URL-адрес ресурса?
• Используйте GET для получения ресурсов
• Чтобы использовать POST для создания нового ресурса
• Чтобы обновить ресурс с помощью PUT
• Чтобы удалить ресурс с помощью DELETE

На самом деле REST — это не все или не совсем так!

Что такое ОТДЫХ

REST означает передачу репрезентативного состояния из докторской диссертации доктора Роя Томаса Филдинга «Архитектурные стили и

Глава 5 Проекта сетевых программных архитектур (статья доктора Филдинга будет обсуждаться отдельно позже), обычно переводимая как «передача репрезентативного состояния».

В первом разделе главы 6 статьи упоминается, почему REST назван так:

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

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

существует"Что такое архитектурные образцы и архитектурные стилиВ статье упоминалось:

• Архитектурный стиль — это набор архитектурных ограничений.
• REST — это архитектурный стиль.

так,REST — это набор архитектурных ограничений.!

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

REST — это составной архитектурный стиль, т.е. он содержит другие архитектурные стили!

Ограничения REST включают: CS, без сохранения состояния, иерархический, кэшированный, единый интерфейс и код по запросу. «Единый интерфейс» — главное отличие REST от других архитектурных стилей! «Единый интерфейс» включает в себя четыре подограничения: идентификацию ресурсов, манипулирование ресурсами через представление, сообщения с самоописанием и гипермедиа как механизм состояния приложения!

«Архитектурные стили и

Пятая глава «Проектирование сетевых программных архитектур» описывает полный процесс создания REST, который кратко описан здесь!

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

Null Style: система без существенных границ между компонентами, архитектура без ограничений

Client-Server:

• ограничение: Разделение задач (клиентский интерфейс и серверное хранилище данных)
• Преимущество: Клиент и сервер могут развиваться независимо. Клиент может взаимодействовать с несколькими серверами, и сервер может легко масштабироваться.
• недостаток: Снижение производительности

Stateless:

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

Cache:

• ограничение: данные в ответе на запрос явно или неявно помечаются как кэшируемые или некэшируемые.
• Преимущество: повышение производительности сети. Если ответ кэшируется, клиентские кэши могут повторно использовать данные ответа для будущих идентичных запросов. Некоторые взаимодействия можно частично или полностью исключить, тем самым повысив эффективность, масштабируемость и воспринимаемую пользователем производительность за счет уменьшения средней задержки серии взаимодействий.
• недостаток:возможноснизить надежность, устаревшие данные в кеше могут сильно отличаться от того, что вы получите, отправив запрос напрямую на сервер.

Uniform Interface(Основные функции REST):

• ограничение: Между компонентами должен быть унифицированный интерфейс, включая четыре дополнительных ограничения:
• идентификация ресурсов(идентификация ресурсов): Каждый ресурс имеет свой идентификатор. Клиенты должны указывать этот идентификатор при запросе. Клиент получает представление ресурса, например, в формате HTML, XML или JSON.
• Управляйте ресурсами, выражая(манипулирование ресурсами через представления): клиент оперирует представлением ресурса, а не самим ресурсом.
• самоописывающее сообщение(самописательные сообщения): Каждое сообщение содержит достаточно информации, чтобы описать, как с ним обращаться.
• Гипермедиа как механизм состояния приложения (HATEOAS)(гипермедиа как механизм состояния приложения): клиент учится управлять представлением через содержимое гипермедиа, предоставляемое сервером, и отправляет операцию представления на сервер, а сервер управляет ресурсом, а затем изменяет состояние. сервера.
• Преимущество:упрощатьОбщая структура,улучшатьвидимость, содействовать независимомуэволюция.
• недостаток:Уменьшенныйэффективность. Информация передается в стандартизированной форме, а не в форме, специфичной для требований приложения.

Layered System:

• ограничение: Разбивает архитектуру на несколько уровней слоев, ограничивая поведение компонентов.
• Преимущество: Ограничивая знания компонента о системе одним уровнем, устанавливает границы для общей сложности системы и увеличиваетНезависимость на дне. Используйте слои для инкапсуляции устаревших сервисов и запуска новых сервисов.Невосприимчивость к устаревшим клиентам; перемещая редко используемые функции в общий промежуточный компонент,Упрощенная реализация компонента. Промежуточные компоненты также могут поддерживать балансировку нагрузки между несколькими сетями и процессорами.Улучшить масштабируемость системы.
• недостаток: увеличивает накладные расходы и задержку обработки данных, поэтомуСнижение воспринимаемой пользователем производительности. Этот недостаток можно исправить, используя общий кэш на среднем уровне.

Code-On-Demand(необязательный):

• ограничение: клиентский компонент знает, как получить доступ к набору ресурсов, но не знает, что с ними делать. Он отправляет запрос на удаленный сервер для кода о том, что делать с ресурсом, получает код и выполняет код локально.
• Преимущество: Возможность добавления функциональности в развернутый клиент, улучшенаМасштабируемость и конфигурируемость; когда код способен адаптировать свои действия к среде клиента и взаимодействовать с пользователем локально, а не удаленно, можно получитьЛучшая воспринимаемая пользователем производительность и эффективность. Улучшает серверМасштабируемость.
• недостаток: Из-за необходимости управлять средой оценки,Уменьшенная простота, что в некоторых случаях можно компенсировать за счет упрощения функциональности статического клиента. Самое большое ограничение связано с тем, что сервер отправляет код вместо простых данных, поэтомуотсутствие видимости. Отсутствие видимости может привести к очевидным проблемам с развертыванием, если клиент не может доверять серверу.

Суммировать:

Возможно, прочитав вывод, вы все еще не знаете, что такое REST! Позвольте мне объяснить, что такое «ОТДЫХ» на примере!

Например

Давайте сначала посмотрим, почему доктор Филдинг разработал REST? Доктор Филдинг упомянул в статье, что он разработал REST, чтобыРуководить проектированием и разработкой современных веб-архитектур.! На основе REST доктор Филдинг разработал HTTP1.1! Другими словами, HTTP1.1 совместим с REST! Итак, чтобы понять REST, если вы понимаете HTTP1.1!

Если вы когда-либо создавали веб-приложение, то CS, многоуровневость, безгражданство и кэширование должны быть хорошо поняты, поэтому я не буду здесь вдаваться в подробности! Код по запросу похож на Flash, Applet и другие веб-приложения для расширения веб-функций!

Здесь мы говорим только об ограничении «унифицированного интерфейса»!

Давайте объясним REST с помощью простого HTTP-запроса!

Например, когда вы вводите www.abc.com:

• Www.abc.com вам перейти на домашнюю страницу сайта по идентификатору, сайт abc будет собран в ответную информацию о домашнем ресурсе обратно в ваш браузер (идентифицированный ресурс)
• В заголовке возвращаемого содержимого (заголовок HTTP) он сообщает браузеру, как обрабатывать возвращенную информацию (сообщение с самоописанием).
• Возвращаемое информационное тело (тело HTTP), обычно в формате HTML, является представлением ресурса домашней страницы, который вы посещаете, который содержит операции, которые вы можете выполнять с этим представлением, например, какие ссылки вы можете получить и какие данные вы можете отправить ( гипермедиа как механизм состояния приложения)
• После перехода по ссылке это операция над представлением, и у вас вообще нет доступа к реальному ресурсу (манипулировать ресурсом через представление)
• После того, как сервер получает ваш запрос, он собирает соответствующие связанные ресурсы в ответное сообщение и возвращает его (в этот момент состояние приложения изменяется).
• После того, как браузер получит ответ, он отобразит страницу, и вы сможете перейти к следующему шагу.

Что такое REST

Вышеизложенное объясняет, что такое «ОТДЫХ»! Теперь давайте объясним, что такое RESTful!

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

Хотя многие системы утверждают, что они RESTful, но на самом деле большинство систем не RESTful или не совсем RESTful! Доктор Филдинг опубликовал сообщение в блоге по этому вопросу, разъяснив, какую систему можно назвать REST-совместимой со мной! В тексте четко указано, что система должна удовлетворять ограничениям HATEOAS, чтобы ее можно было назвать REST-совместимой! И HATEOAS трудно достичь! Потому что кто-то участвует!

Чтобы облегчить это затруднение, Ричардсон предложил «Модель зрелости REST». Эта модель делит сервисы REST на 4 уровня в зависимости от зрелости:

• **Первый уровень (уровень 0)** Веб-сервисы просто используют HTTP в качестве транспорта, что на самом деле является лишь особой формой удаленного вызова методов (RPC). И SOAP, и XML-RPC попадают в эту категорию.
• **Второй уровень (уровень 1)** веб-служб знакомит с концепцией ресурсов. Каждый ресурс имеет соответствующий идентификатор и представление.
• **Уровень 2** Веб-службы используют разные методы HTTP для выполнения разных операций и используют коды состояния HTTP для указания разных результатов. Например, метод HTTP GET для получения ресурсов, метод HTTP DELETE для удаления ресурсов.
• **Уровень 3** Веб-службы используют HATEOAS. Информация о ссылке включена в представление ресурса. Клиенты могут обнаруживать действия, которые могут быть выполнены на основе ссылки.

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

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

Большинство систем, претендующих на звание RESTful, сейчас могут достичь только третьего уровня!

Трудности HATEOAS

Почему трудно достичь HATEOAS? Потому чтоКлиент не может решить! HTTP может достичь RESTful, потому что браузер отображает только представление и параметры работы для ресурса.Что касается конкретной операции, это зависит от человека, который использует браузер! То есть, хотя сервер сообщает клиенту варианты операции, клиент не может знать, что выбрать!

Просмотр веб-страниц предполагает участие человека, но RESTful API не задействован, что затрудняет для клиента RESTful API принятие решения о том, что делать!

Возможные решения:

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

использованная литература

• Architectural Styles and the Design of Network-based Software Architectures
• REST APIs must be hypertext-driven