REST сам по себе является очень абстрактным архитектурным стилем, поэтому всегда трудно иметь глубокое и впечатляющее его понимание. Цель написания этой статьи — обобщить мои собственные знания о REST, и я надеюсь, что благодаря этой статье читатели смогут по-настоящему понять REST.
Основное содержание этой статьи
- Что такое ОТДЫХ
- Концепции REST
- Происхождение ОТДЫХА
- Понимание REST
- Архитектурные ограничения для REST
- модель клиент/сервер
- нет статуса
- тайник
- Единый интерфейс
- многоуровневая система
- резюме
- Суммировать
Что такое ОТДЫХ
Концепция ОТДЫХА
Давайте посмотрим на определение REST, данное Baidu:
REST is Representational State Transfer (англ. Representational State Transfer, сокращенно REST) — это своего рода метод, предложенный доктором Роем Филдингом в его докторской диссертации в 2000 году.Архитектура программного обеспечениястиль. этоИнтернет-приложениеЭто может уменьшить сложность разработки и улучшить масштабируемость системы.
- Мы называем REST большеИзобразительное State Transfer.
- Так называемый переход репрезентативного состояния является репрезентацией чего? ——ресурс
- REST опускает тему Resource (ресурс), полное имя — Resource Representational State Transfer, то естьПередача репрезентативного состояния ресурсов. С точки зрения непрофессионала, это означает, что ресурсы передают состояние в той или иной форме представления в сети.
- Если архитектура соответствует принципам REST, она называется архитектурой RESTful.
Прежде чем углубиться в объяснение REST, давайте взглянем на происхождение REST, которое имеет решающее значение для понимания REST.
Происхождение ОТДЫХА
Сначала кратко познакомьтесь с автором -Roy Thomas Fielding
- Член группы экспертов по протоколу HTTP/1.0.
- Группа экспертов по протоколу HTTP/1.1главный
- Основной разработчик HTTP-сервера Apache
- Соучредитель Apache Software Foundation
Диаграмма, иллюстрирующая происхождение REST:
Что ж, это очень грубая диаграмма, но ее достаточно, чтобы объяснить происхождение REST. История начинается с протокола HTTP/1.0 в древние времена.С развитием веб-технологий протокол HTTP/1.0, который использовался много лет и ориентирован на статические документы, не может удовлетворить потребности разработки веб-приложений.Являясь одним из среди членов группы экспертов по протоколу HTTP/1.0 Рой Филдинг выделился и стал главой группы экспертов по протоколу HTTP/1.1, отвечая за координацию разработки новой версии протокола. В процессе формулировки протокола HTTP/1.1 Рой Филдинг и его коллеги провели углубленное исследование и подытожили большой успех Интернета на уровне технической архитектуры, а затем включили эти выводы в набор теоретических основ. используйте руководящие принципы в этой теоретической структуре, чтобы определить направление разработки протокола HTTP/1.1. После трех лет доработок протокол HTTP/1.1 официально стал нормой в июне 1999 года. Проект протокола HTTP/1.1 был настолько успешным, что через десять лет после его выпуска немногие почувствовали необходимость его пересмотра. Филдинг вернулся в Калифорнийский университет в Ирвине, чтобы продолжить работу над докторской диссертацией после завершения разработки протокола HTTP/1.1. На втором курсе (2000 г.) в своей докторской диссертации «Архитектурные стили и проектирование сетевой архитектуры программного обеспечения» (китайская версия под названием «Архитектурные стили и проектирование сетевой архитектуры программного обеспечения») более систематически и строго излагает эту теоретическую основу. , и новый архитектурный стиль получен с использованием этой теоретической основы, и беззаботное название для этого архитектурного стиля - «ОТДЫХ» - Репрезентативный Аббревиатура от State Transfer. Это происхождение REST.Можно увидеть, что архитектурный стиль REST суммируется путем получения технических архитектурных факторов сети, а обобщенная теоретическая основа используется для определения направления проектирования протокола HTTP/1.1. Тогда мы можем понять это следующим образом: REST — это архитектурный стиль самой сети, а REST — это рекомендации по проектированию для веб-спецификаций, таких как протокол HTTP/1.1 Протокол HTTP/1.1 предназначен для реализации архитектуры в стиле REST.
Понимание REST
что такое веб
Из источников REST мы обнаружили, что для того, чтобы глубоко понять REST, мы должны сначала понять сеть. Давайте взглянем на некоторые знания, связанные с Интернетом:
Интернет-энциклопедия Baidu (Всемирная паутина) — это глобальная глобальная сеть, также известная как Всемирная паутина, которая представляет собой глобальную, динамическую, интерактивную, кросс-платформенную распределенную графическую информационную систему, основанную на гипертексте и HTTP. Это сетевая служба, созданная в Интернете, которая предоставляет браузерам графический, удобный и интуитивно понятный интерфейс для поиска и просмотра информации в Интернете.Документы и гиперссылки в нем организуют информационные узлы в Интернете в интерактивный Ассоциированная сетевая структура.
ВикипедияВсемирная сеть(Английский:World Wide Web), также известная как «WWW», «Web», представляет собой систему множества взаимосвязанных гипертекстов, доступ к которым осуществляется через Интернет. Всемирная паутина — это не то же самое, что Интернет.Всемирная паутина — это только одна из услуг, которые может предоставить Интернет, и это служба, которая работает в Интернете.Интернета такжеВсемирная сетьТермины используются часто без особого различия. Однако это не одно и то же. Интернет представляет собой глобальную систему взаимосвязанных компьютерных сетей. Напротив, World Wide Web представляет собой глобальную коллекцию документов и других ресурсов, связанных гиперссылками и URI. Доступ к ресурсам всемирной паутины обычно осуществляется с использованием HTTP, типа протокола связи в Интернете. Основная часть World Wide Web состоит из трех стандартов:
- Унифицированный идентификатор ресурса (URI), представляющий собой единую систему поиска ресурсов.
- Протокол передачи гипертекста (HTTP), который отвечает за определение того, как клиенты и серверы взаимодействуют друг с другом.
- Язык гипертекстовой разметки (HTML), определяющий структуру и формат гипертекстовых документов.
Подводя итог, можно сказать, что сеть представляет собой систему, состоящую из множества взаимосвязанных гипертекстов, которые используют URI для поиска каждого ресурса в системе и обмена данными через протокол HTTP. Говоря более абстрактно, Интернет — это распределенная информационная система, предоставляющая интерфейсы и механизмы доступа к гипертекстовым документам и другим объектам (ресурсам). Поняв, что такое Интернет, мы сможем лучше понять, что такое REST. Что касается архитектурного стиля самой паутины, то непосредственно делаем выводы:REST — это, по сути, решение прикладного уровня для распределенной системы гипермедиа.Он предлагает ряд архитектурных ограничений и принципов для разделения взаимодействия ресурсов и управления ресурсами, в результате чего создается сетевая сеть с сильными функциями, хорошей производительностью и подходящим коммуникационным прикладным программным обеспечением. архитектура.Этот вывод все еще трудно понять, но нам нужно иметь концептуальное понимание его. Далее мы представим REST более подробно.
ОТДЫХА фраза
Чтобы понять REST, вам сначала нужно понять фразу (Resource) Representational State Transfer.
Ресурс
Основная абстракция REST для информации — это ресурсы. Ресурсом может служить любая информация, которая может быть названа: документ, служба, связанная со временем (например, «Сегодняшняя погода в Лос-Анджелесе»), совокупность других ресурсов, не виртуальный объект (например, человек), и т.д. Подождите. Другими словами, любое понятие, которое может быть целью авторской гипертекстовой ссылки, должно соответствовать определению ресурса. Ресурс — это концептуальное отображение набора сущностей, а не самих сущностей, связанных с отображением в любой момент времени. Точнее, ресурс R является изменяющейся во времени функцией-членом.
Эта функция сопоставляет ресурс с сущностью или набором значений на основе времени t, значения в наборе могут бытьПредставление ресурсов(ресурс представления) и/илиидентификатор ресурса(идентификаторы ресурсов) (оба эквивалентны). Для ресурса единственное, что должно быть статическим, — это семантика отображения, потому что семантика — это ключ к различению ресурсов. Именно это абстрактное определение ресурсов позволяет реализовать основные функциональные возможности веб-архитектуры. Во-первых, он содержит множество источников информации без их искусственного разграничения по типу или реализации, что обеспечивает общность. Во-вторых, он допускает позднее связывание ссылок с представлениями, тем самым обеспечивая согласование контента на основе характера запроса. Наконец, это позволяет автору ссылаться на понятие, а не на одно представление понятия, так что при изменении представления нет необходимости изменять все существующие ссылки (при условии, что автор использовал правильный идентификатор).
Как понять предложение «Для ресурса единственное, что должно быть статическим, — это семантика отображения, потому что семантика — это ключ к различению ресурсов»? Чтобы проиллюстрировать это на простом примере: «Текущая версия приложения» — это ресурс, и «самая стабильная версия приложения» — это тоже ресурс, хотя в какой-то момент эти два ресурса могут сопоставляться с одним и тем же значением, но они различны, и эти два ресурса могут быть идентифицированы и упомянуты независимо друг от друга.
идентификатор ресурса
Использование RESTидентификатор ресурсадля представления конкретных ресурсов, участвующих во взаимодействиях между компонентами. Соединитель REST предоставляет общий интерфейс для доступа и управления набором значений ресурса, независимо от того, как определена его функция членства или какой тип программного обеспечения обрабатывает запрос. Уполномоченный по именованию присваивает идентификаторы ресурса ресурсам, делая возможным обращение к ресурсам, и тот же самый орган по именованию поддерживает семантическую достоверность отображения (например, гарантируя, что функции-члены не изменяются). Традиционные гипертекстовые системы обычно работают только в закрытой или локализованной среде, они используют уникальные идентификаторы узлов или документов, которые изменяются вместе с информацией, и полагаются на серверы ссылок (ссылка server) для поддержки ссылок независимым от содержимого способом. Поскольку централизованные серверы ссылок совершенно не подходят для большого масштаба Интернета и охвата нескольких организационных доменов, REST использует другой подход — создатели ресурсов выбирают идентификаторы ресурсов, которые лучше всего соответствуют сути идентифицируемой концепции.
Идентификаторы ресурсов предоставляют общий интерфейс для доступа и управления наборами значений ресурсов. Другими словами, ресурсы, которые мы абстрагируем, должны быть идентифицируемыми и иметь очевидный идентификатор — в Интернете унифицированная концепция идентификатора: URI (унифицированный идентификатор ресурса). URI образуют глобальное пространство имен, и использование URI для идентификации ключевых ресурсов означает, что эти ресурсы получают уникальный глобальный идентификатор. В качестве простого примера: представьте, какое ужасное бизнес-решение было бы иметь на онлайн-рынке, таком как Amazon.com, не идентифицирующем каждый из своих товаров уникальным идентификатором (URI).
Представительства
Представление ресурса — это описание состояния ресурса в конкретный момент. Конкретное представление ресурсов во внешнем мире может иметь несколько представлений (или представлений, представлений), причем между клиентом и сервером также передается представление ресурсов, а не сами ресурсы. Например, текстовые ресурсы могут быть в форматах html, xml, json и других, а картинки могут отображаться в PNG или JPG. Представление ресурса включает в себя данные и метаданные, описывающие данные, например, HTTP-заголовок «Content-Type» является одним из таких атрибутов метаданных. Точнее:
Компоненты REST используютвыражатьВыполняйте действия над ресурсом, фиксируя текущее или ожидаемое состояние ресурса, а затем передавая это представление между компонентами. Представление имеет последовательность байтов и описание этих байтов.метаданные представления(представление метаданных) композиция. Другие распространенные, но неточные имена для представления включают: документ, файл, сущность сообщения HTTP, экземпляр или переменную. Представление состоит из данных, метаданных, описывающих данные, и (иногда присутствующих) метаданных, описывающих метаданные (обычно используемые для проверки целостности сообщения). Формат данных представления называется типом носителя.
Кратко резюмируя:
- Ресурсы всегда отображаются как носитель какого-либо представления, то есть сериализованной информации.
- Представление ресурсов — это уровень представления архитектуры REST.
- Ресурсы могут иметь несколько представлений
переход состояния
Передача состояния: передача представления, представляющего состояние ресурса, между клиентом и сервером. Передавая и манипулируя представлением ресурсов, цель манипулирования ресурсами достигается косвенно. Посещение веб-сайта представляет собой интерактивный процесс между клиентом и сервером. В этом процессе обязательно будут задействованы данные и изменения состояния. Протокол Интернет-коммуникации HTTP-протокол — это протокол без сохранения состояния. Это означает, что все состояние ресурсов хранится на стороне сервера. Следовательно, если клиент хочет оперировать ресурсами на сервере, он должен использовать некоторые средства, чтобы сделать серверные ресурсы «передачей состояния» (State Transfer). И это преобразование основано на представлении, так что это «передача репрезентативного состояния». Метод, используемый клиентом, — это протокол HTTP в Интернете. В частности, в протоколе HTTP есть четыре глагола, которые выражают режим работы: GET, POST, PUT, DELETE. Они соответствуют четырем основным операциям:
- ПОЛУЧИТЬ - получить ресурс
- POST — создать новый ресурс (также можно использовать для обновления ресурса)
- PUT - обновить ресурс
- УДАЛИТЬ - удалить ресурс
резюме
Передача репрезентативного состояния ресурсов, передача репрезентативного состояния ресурсов, то есть: ресурсы, абстрагированные от данных, в той или иной форме выражения, с помощью некоторых средств, передача состояния происходит в сети, чтобы косвенно достичь цели операционных ресурсов. Архитектурный стиль Representational State Transfer (REST) — это абстракция архитектурных элементов в распределенных гипермедиа-системах. В сети, в частности:
- Каждый URI представляет ресурс;
- Между клиентом и сервером проходит какой-то уровень представления этого ресурса;
- Клиент работает с ресурсами на стороне сервера с помощью четырех HTTP-команд для достижения «преобразования состояния уровня представления».
Давайте взглянем на эту проблему с другой стороны и подумаем о построении системы: в Интернете, чтобы получить ресурсы гипермедиа, которые нам нужны, распределенные по разным регионам, как мы должны спроектировать эту систему? Очевидно, что в сети существует большое количество ресурсов разного типа, распределенных в разных местах. Что нам нужно предоставить, так это решение прикладного уровня для крупномасштабной распределенной гипермедиа-системы. Сначала нам нужно однозначно идентифицировать данные, которые нам нужны, поэтому мы абстрагируем данные в ресурсы и используем унифицированный идентификатор ресурса (URI), чтобы установить идентификатор для каждого ресурса, чтобы у нас был способ манипулировать каждым ресурсом. Так как же манипулировать ресурсами? Другими словами, когда мы видим URI и вводим его в браузер, почему браузер знает, что делать с URI? На самом деле причина, по которой браузеры умеют обрабатывать URI, заключается в том, что все ресурсы поддерживают один и тот же интерфейс (URI) и один и тот же набор методов (HTTP-глаголы). Таким образом, когда мы определяем наши собственные ресурсы таким образом, другие в сети могут легко получить эти ресурсы. При приобретении ресурсов нам могут понадобиться разные методы представления или требования, поэтому нам необходимо выражать ресурсы в нужной нам форме.
Глядя на REST с точки зрения распределенных систем, мы обнаруживаем, что ориентированный на ресурсы REST действительно обеспечивает решение для крупномасштабных систем с распределенными ресурсами, и успех Интернета действительно подтвердил правильность этой теории.
Архитектурные ограничения для REST
REST как архитектурный стиль для организации веб-сервисов предлагает ряд ограничений на архитектурном уровне. Система называется RESTful, если она удовлетворяет этим ограничениям. Далее мы рассмотрим пять необходимых ограничений REST поэлементно.
модель клиент/сервер
Коммуникация может быть инициирована только клиентом в одностороннем порядке, в форме запрос-ответ.
Принцип, лежащий в основе ограничений клиент-сервер, заключается в разделении задач. Разделяя две задачи пользовательского интерфейса и хранения данных, мы улучшаем переносимость пользовательского интерфейса на несколько платформ и в то же время улучшаем масштабируемость системы за счет упрощения серверных компонентов. Однако наиболее важно для Интернета то, что такое разделение задач позволяет компонентам развиваться независимо, чтобы поддерживать потребности регулирования Интернета в нескольких организационных доменах.
нет статуса
Затем мы добавляем архитектурное ограничение для взаимодействия клиент-сервер: связь должна быть по своей природе без сохранения состояния, каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать никакую информацию, хранящуюся на сервере. Таким образом, контекст клиентской стороны, состояние сеанса хранятся на клиентской стороне.
Когда мы ранее анализировали фразу REST, мы упомянули передачу состояния ресурсов, и здесь ограничение REST включает принцип связи без состояния, что кажется противоречием: поскольку «без состояния», как мы можем сказать «передача состояния» Woolen ткань? На самом деле упомянутый здесь принцип связи без сохранения состояния означает не то, что клиентское приложение не может сохранять состояние, а то, что сервер не должен сохранять состояние клиента.
Состояние приложения и состояние ресурса
Состояние должно различать состояние приложения и состояние ресурса.Клиент отвечает за поддержание состояния приложения, а сервер поддерживает состояние ресурса. Взаимодействие клиент-сервер не должно иметь состояния, и каждый запрос должен содержать всю информацию, необходимую для обработки запроса. Серверу не нужно сохранять состояние приложения между запросами, сервер обращает внимание на состояние приложения только при получении фактического запроса. Этот принцип связи без сохранения состояния позволяет серверам и посредникам понимать независимые запросы и ответы. При выполнении нескольких запросов один и тот же клиент больше не должен зависеть от одного и того же сервера, что упрощает реализацию высокомасштабируемого и высокодоступного сервера.
преимущество
- Видимость — системе мониторинга не нужно просматривать несколько запросов вне запроса, чтобы определить полный характер запроса.
- Надежность — облегчает работу по восстановлению после частичных сбоев.
- Масштабируемость — отсутствие необходимости сохранять состояние при нескольких запросах позволяет компонентам сервера быстро высвобождать ресурсы и еще больше упрощает их реализацию, поскольку серверу не нужно управлять использованием ресурсов при нескольких запросах.
недостаток
Поскольку данные о состоянии нельзя хранить в общем контексте сервера, увеличивается количество дублирующихся данных, отправляемых в серии запросов (накладные расходы на каждое взаимодействие), что потенциально снижает производительность сети. Кроме того, размещение состояния приложения на стороне клиента снижает способность сервера контролировать согласованное поведение приложения, поскольку в этом случае приложение зависит от правильной реализации семантики нескольких версий клиента.
тайник
Чтобы повысить эффективность сети, мы добавляем кэширование в качестве архитектурного ограничения. Архитектура кэширования требует, чтобы данные в ответе на запрос были неявно или явно помечены как кэшируемые или некэшируемые. Если ответ кэшируется, клиентский кэш может повторно использовать данные ответа для последующих запросов того же самого.
преимущество
Добавление кэширования может частично или полностью устранить некоторые взаимодействия, тем самым повысив эффективность, масштабируемость и воспринимаемую пользователем производительность за счет уменьшения средней задержки последовательности взаимодействий.
недостаток
Кэширование может снизить надежность, если устаревшие данные в кеше существенно отличаются от данных, полученных при отправке запроса напрямую на сервер.
Единый интерфейс
Основной особенностью, которая отличает архитектурный стиль REST от других архитектурных стилей, основанных на веб-технологиях, является акцент на едином интерфейсе между компонентами. Применяя общие принципы разработки программного обеспечения к интерфейсам компонентов, системная архитектура Zhengte упрощается, а взаимодействие улучшается. Реализации не связаны с сервисами, которые они предоставляют, что способствует независимому развитию. Однако цена, которую придется заплатить, заключается в том, что единый интерфейс снижает эффективность, поскольку информация передается в стандартизированной форме, а не в форме требований, специфичных для приложения. Интерфейс REST предназначен для эффективной передачи крупномасштабных данных гипермедиа и оптимизирован для распространенных сценариев в Интернете, но это также делает интерфейс неоптимальным для других форм архитектурного взаимодействия.
Для достижения единого интерфейса необходимо наличие нескольких архитектурных ограничений, определяющих поведение компонентов. REST определяется четырьмя архитектурными ограничениями интерфейса:
- идентификация ресурсов
- Манипулирование ресурсами через представления
- самоописательные сообщения
- Гипермедиа как механизм состояния приложения (сокращенно HATEOAS)
идентификация ресурсов
Каждый ресурс имеет идентификатор ресурса. Идентификатор ресурса каждого ресурса может использоваться для уникальной идентификации этого ресурса.
Управление ресурсами через представления
Здесь мы говорим о самоописывающей природе ресурса. Ресурс, возвращаемый системой REST, должен уметь описывать себя и предоставлять достаточно информации для управления ресурсом, например, как добавлять, удалять и изменять ресурс. То есть типичная служба REST не требует дополнительной документации о том, как манипулировать ресурсами.
самоописывающая информация
Самоописывающий характер сообщения. Сообщения, передаваемые в системе REST, должны предоставлять достаточно информации о том, как они обрабатываются. Например, тип MIME, используемый сообщением, можно ли его кэшировать и т. д.
Гипермедиа как механизм состояния приложения
То есть клиент может получить информацию, необходимую для следующей операции, только через информацию, содержащуюся в каждом результате, возвращаемом сервером, например, на какой URL-адрес отправить запрос. То есть типичная служба REST не требует дополнительной документации, чтобы указать, какие URL-адреса используются для доступа к определенному типу ресурса, а вместо этого указывает, какие операции могут быть выполнены с ресурсом через ответ, возвращаемый сервером. Клиенту службы REST также не нужно знать никакой такой информации о том, какие там ресурсы.
В основе этого описания лежит концепция гипермедиа, другими словами: идея ссылок. Ссылки — это обычное понятие, которое мы видим в HTML, но их полезность ни в коем случае не ограничивается этим (для людей, просматривающих Интернет). Рассмотрим следующий вымышленный фрагмент XML:
<order self="http://example.com/customers/1234"> <amount>23</amount> <product ref="http://example.com/products/4554"> <customer ref="http://example.com/customers/1234"> </customer> </product></order>Если вы посмотрите на ссылки продукта и клиента в документации, то легко представить, как приложение (которое уже получило документацию) «следует» по ссылкам для получения дополнительной информации. Конечно, использование простого атрибута «id» в качестве ссылки, соответствующей проприетарному соглашению об именах, также возможно, но только в контексте приложения. Прелесть использования URI для представления ссылок заключается в том, что ссылки могут указывать на ресурсы, предоставляемые разными приложениями, разными серверами или даже разными компаниями, расположенными на другом континенте. могут быть взаимосвязаны. Есть еще один важный аспект принципов гипермедиа — «состояние» приложения. Короче говоря, серверная часть (или сервис-провайдер, если хотите) фактически предоставляет набор ссылок клиенту (потребителю сервисов), через которые клиент может переводить приложение из одного состояния в другое. А пока просто помните: ссылки — очень эффективный способ создания динамических приложений. Этот принцип резюмируется следующим образом: По возможности используйте ссылки для ссылок на вещи (ресурсы), которые можно идентифицировать. Именно гиперссылки делают Интернет тем, чем он является сегодня.
многоуровневая система
Для дальнейшего улучшения поведения, связанного с требованием масштабирования Интернета, мы добавили архитектурные ограничения многоуровневой системы. Стиль многоуровневой системы разбивает архитектуру на слои, ограничивая поведение компонентов (то есть каждый компонент «видит» только соседние слои, с которыми он взаимодействует). Ограничивая знания компонента о системе одним уровнем, он устанавливает границы общей сложности системы и повышает базовую независимость. Мы можем использовать уровни для инкапсуляции устаревших сервисов и изоляции новых сервисов от устаревших клиентов, перемещая менее часто используемые функции в общий промежуточный компонент, что упрощает реализацию компонента. Промежуточные компоненты также могут улучшить масштабируемость системы, поддерживая балансировку нагрузки между несколькими сетями и процессорами.
Промежуточное ПО: Промежуточное ПО — это независимое системное программное обеспечение или сервисная программа, которая может соединять два независимых программного обеспечения или системы. Распределенное прикладное программное обеспечение может совместно использовать ресурсы между различными технологиями с помощью промежуточного программного обеспечения. То есть промежуточное ПО позволяет нескольким независимым системам взаимодействовать через промежуточное ПО, даже если каждая из них имеет разные интерфейсы. Ключевым способом выполнения промежуточного программного обеспечения является передача информации. С помощью промежуточного программного обеспечения приложения могут работать на нескольких платформах и в различных операционных средах. Короче говоря, промежуточное ПО — это мост.
Основной недостаток многоуровневых систем: увеличение накладных расходов и задержек при обработке данных, что снижает воспринимаемую пользователем производительность. Для сетевой системы, которая поддерживает архитектурные ограничения кэша, этот недостаток может быть компенсирован преимуществами, получаемыми от использования общих кэшей на среднем уровне.
резюме
Архитектурный стиль REST состоит из выбранного набора архитектурных ограничений, с помощью которых желаемые архитектурные свойства создаются в архитектурах-кандидатах. Хотя каждое из этих архитектурных ограничений можно рассматривать независимо, описание их с точки зрения их происхождения в общих архитектурных стилях облегчает понимание теории, лежащей в основе их выбора.
Суммировать
В этой статье делается попытка понять, что такое REST по сути. Мы начнем с происхождения REST, обнаружим существенную связь между REST и Интернетом и придем к выводу, что REST по сути является решением прикладного уровня для распределенной системы гипермедиа, исходя из характеристик Интернета. Затем мы провели подробный анализ фразы REST, а именно (Resource)Representational State Transfer (передача репрезентативного состояния ресурсов), и в дальнейшем получили ресурсоцентричный архитектурный стиль REST. Наконец, мы подробно разрабатываем и объясняем пять необходимых ограничений архитектуры REST, чтобы читатели могли глубже понять REST. Даже если эта статья здесь, я все еще чувствую, что мне не хватает знаний, когда я пишу это содержание, поэтому я не могу глубже понять REST. Этот блог автора не только надеется сделать краткий обзор того, что я узнал, но и надеется помочь другим новичкам. Если есть какие-то неуместные понимания в тексте, критика и указания приветствуются.