REST: различия между версиями

Интерактивная навигация по истории

(Показать все непатрулированные изменения)

[отпатрулированная версия]

[непроверенная версия]

← Предыдущая правка

Содержимое удалено Содержимое добавлено

ВизуальныйВики-текст

Линейный

Текущая версия от 14:18, 7 февраля 2024

REST (от англ. REpresentational State Transfer — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Другими словами, REST — это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать^[1]. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы; прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле^{[уточнить]} компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC^[2].

В интернете вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса^[3]^[4].

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.

История термина

Хотя данная концепция лежит в самой основе Всемирной паутины, термин «REST» был введён Роем Филдингом, одним из создателей протокола «HTTP», лишь в 2000 году^[4]. В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures»)^[5] в Калифорнийском университете в Ирвайне^[3] он подвёл теоретическую основу под способ взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей представительного состояния» («Representational State Transfer»). Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).

Стиль «REST» развивался параллельно с «HTTP 1.1», разработанным в 1996—1999 годах, основываясь на существующем дизайне «HTTP 1.0», разработанном в 1996 году^[6].

Свойства архитектуры REST

Свойства архитектуры, которые зависят от ограничений, наложенных на REST-системы:

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

Рой Филдинг (один из главных авторов спецификации протокола HTTP) описывает влияние архитектуры REST на масштабируемость следующим образом:

Простота унифицированного интерфейса;
Открытость компонентов к возможным изменениям для удовлетворения изменяющихся потребностей (даже при работающем приложении);
Прозрачность связей между компонентами системы для сервисных служб;
Переносимость компонентов системы путём перемещения программного кода вместе с данными;
Надёжность, выражающаяся в устойчивости к отказам на уровне системы при наличии отказов отдельных компонентов, соединений или данных.^[3]

Требования к архитектуре REST

Существует пять обязательных^[7]^[8] ограничений для построения распределённых REST-приложений по Филдингу^[3]^[9] и одно необязательное.

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

Если сервис-приложение нарушает любое из этих ограничительных условий, данную систему нельзя считать REST-системой^[3].

Обязательными условиями-ограничениями являются:

1. Модель клиент-сервер

Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.^[3]

2. Отсутствие состояния

Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится (Stateless protocol или «протокол без сохранения состояния»). Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента^[3]. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.

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

3. Кэширование

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

4. Единообразие интерфейса

Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов^[3]. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.

К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия^[10]^[11]:

Идентификация ресурсов
Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.

Манипуляция ресурсами через представление
Если клиент хранит представление ресурса, включая метаданные — он обладает достаточной информацией для модификации или удаления ресурса.

«Самоописываемые» сообщения
Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру, обработчик сообщения (parser), необходимый для извлечения данных, может быть указан в списке MIME-типов^[3].

Гипермедиа как средство изменения состояния приложения (HATEOAS)
Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, Web Linking (RFC 5988 -> RFC 8288) и JSON Hypermedia API Language Архивная копия от 27 июня 2014 на Wayback Machine являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.

5. Слои

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

6. Код по требованию (необязательное ограничение)

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

Преимущества

Рой Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества^[3]^[9]:

Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);
Производительность (за счёт использования кэша);
Масштабируемость;
Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
Простота интерфейсов;
Портативность компонентов;
Лёгкость внесения изменений;
Способность эволюционировать, приспосабливаясь к новым требованиям (на примере Всемирной паутины).

Примечания

↑ Что такое REST API (рус.). Дата обращения: 11 августа 2021. Архивировано 11 августа 2021 года.
↑ Машнин Тимур Сергеевич. Технология Web-сервисов платформы Java. — БХВ-Петербург, 2012. — С. 115. — 560 с. — ISBN 978-5-9775-0778-3.
↑ ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ¹⁰ Chapter 5 of Roy Fielding’s dissertation «Representational State Transfer (REST)» Архивная копия от 13 мая 2021 на Wayback Machine
↑ ¹ ² Fielding discussing the definition of the REST term (неопр.). Tech.groups.yahoo.com. Дата обращения: 28 ноября 2013. Архивировано 22 октября 2010 года.
↑ Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST) (неопр.). www.ics.uci.edu. Дата обращения: 1 декабря 2015. Архивировано 13 мая 2021 года.
↑ rest-discuss : Message: Re: [rest-discuss] RFC for REST? (неопр.) (11 ноября 2009). Дата обращения: 1 декабря 2015. Архивировано 11 ноября 2009 года.
↑ Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST (неопр.) / Thomas Erl. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
↑ Richardson, Leonard; Ruby, Sam (2007), RESTful Web service, O'Reilly Media, ISBN 978-0-596-52926-0, Дата обращения: 18 января 2011, The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation. Источник (неопр.). Дата обращения: 30 ноября 2016. Архивировано 19 февраля 2012 года.
↑ ¹ ² Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
↑ Wilde, Pautasso, 2011, REST Definition.
↑ Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012
↑ Hartley Brody. How HTTPS Secures Connections: What Every Web Dev Should Know (англ.). Архивировано 24 декабря 2015 года.

Литература

Erik Wilde, Cesare Pautasso. REST: From Research to Practice. — Springer Science & Business Media, 2011. — 528 p. — ISBN 978-1-4419-8303-9.

Ссылки

Roy Fielding. Architectural Styles and the Design of Network-based Software Architectures (англ.) (2000). Дата обращения: 20 февраля 2009. Архивировано 15 мая 2012 года.
Cesare Pautasso; Olaf Zimmerman; Frank Leymann.: RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision (англ.). 17th International World Wide Web Conference (WWW2008). Дата обращения: 20 февраля 2009. Архивировано 15 мая 2012 года.
Джон Фландерс. Введение в службы RESTful с использованием WCF (неопр.). MSDN Magazine (январь 2009). Дата обращения: 20 февраля 2009. Архивировано 15 мая 2012 года.
Alex Rodriguez. RESTful Web services: The basics (англ.). IBM. Дата обращения: 15 декабря 2015. Архивировано 22 декабря 2015 года.
Todd Fredrich. REST API Tutorial (англ.). Дата обращения: 27 октября 2016. Архивировано 25 февраля 2017 года.

[1] Что такое REST API (рус.). Дата обращения: 11 августа 2021. Архивировано 11 августа 2021 года.

[2] Машнин Тимур Сергеевич. Технология Web-сервисов платформы Java. — БХВ-Петербург, 2012. — С. 115. — 560 с. — ISBN 978-5-9775-0778-3.

[Fielding-Ch5-3] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ¹⁰ Chapter 5 of Roy Fielding’s dissertation «Representational State Transfer (REST)» Архивная копия от 13 мая 2021 на Wayback Machine

[autogenerated1-4] ¹ ² Fielding discussing the definition of the REST term (неопр.). Tech.groups.yahoo.com. Дата обращения: 28 ноября 2013. Архивировано 22 октября 2010 года.

[5] Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST) (неопр.). www.ics.uci.edu. Дата обращения: 1 декабря 2015. Архивировано 13 мая 2021 года.

[6] rest-discuss : Message: Re: [rest-discuss] RFC for REST? (неопр.) (11 ноября 2009). Дата обращения: 1 декабря 2015. Архивировано 11 ноября 2009 года.

[SOA_with_REST-7] Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST (неопр.) / Thomas Erl. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.

[Richardson_2007-8] Richardson, Leonard; Ruby, Sam (2007), RESTful Web service, O'Reilly Media, ISBN 978-0-596-52926-0, Дата обращения: 18 января 2011, The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation. Источник (неопр.). Дата обращения: 30 ноября 2016. Архивировано 19 февраля 2012 года.

[SOAwithREST-9] ¹ ² Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.

[_a0e7ce7946f0bdab-10] Wilde, Pautasso, 2011, REST Definition.

[11] Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012

[12] Hartley Brody. How HTTPS Secures Connections: What Every Web Dev Should Know (англ.). Архивировано 24 декабря 2015 года.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

@@ Строка 1: / Строка 1: @@
-'''REST''' (от {{lang-en|'''Re'''presentational '''S'''tate '''T'''ransfer}} — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — [[Архитектура программного обеспечения|архитектурный стиль]] взаимодействия компонентов распределённого приложения в [[вычислительная сеть|сети]]. Другими словами, REST — это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать.<ref>{{Cite web|lang=ru-RU|url=https://www.youtube.com/watch?v=J4Fy6lmLBr0|title=Что такое REST API|access-date=2021-08-11|archive-date=2021-08-11|archive-url=https://web.archive.org/web/202108111430/https://www.youtube.com/watch?v=J4Fy6lmLBr0|deadlink=no}}</ref> REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой [[гипермедиа]]-системы. В определённых случаях ([[интернет-магазин]]ы, [[Поисковая система|поисковые системы]]; прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле{{уточнить}} компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во [[Всемирная паутина|Всемирной паутине]]. REST является альтернативой [[Удалённый вызов процедур|RPC]]<ref>{{книга|автор=Машнин Тимур Сергеевич|заглавие=Технология Web-сервисов платформы Java|издательство=БХВ-Петербург|год=2012|страницы=115|страниц=560|isbn=978-5-9775-0778-3|ответственный=|издание=|место=|isbn2=}}</ref>.
+'''REST''' (от {{lang-en|'''RE'''presentational '''S'''tate '''T'''ransfer}} — «передача репрезентативного состояния» или «передача „самоописываемого“ состояния») — [[Архитектура программного обеспечения|архитектурный стиль]] взаимодействия компонентов распределённого приложения в [[вычислительная сеть|сети]]. Другими словами, REST — это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать<ref>{{Cite web|lang=ru-RU|url=https://www.youtube.com/watch?v=J4Fy6lmLBr0|title=Что такое REST API|access-date=2021-08-11|archive-date=2021-08-11|archive-url=https://web.archive.org/web/202108111430/https://www.youtube.com/watch?v=J4Fy6lmLBr0|deadlink=no}}</ref>. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой [[гипермедиа]]-системы. В определённых случаях ([[интернет-магазин]]ы, [[Поисковая система|поисковые системы]]; прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле{{уточнить}} компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во [[Всемирная паутина|Всемирной паутине]]. REST является альтернативой [[Удалённый вызов процедур|RPC]]<ref>{{книга|автор=Машнин Тимур Сергеевич|заглавие=Технология Web-сервисов платформы Java|издательство=БХВ-Петербург|год=2012|страницы=115|страниц=560|isbn=978-5-9775-0778-3|ответственный=|издание=|место=|isbn2=}}</ref>.
 В [[Интернет|интернете]] [[Удалённый вызов процедур|вызов удалённой процедуры]] может представлять собой обычный [[HTTP]]-запрос (обычно [[HTTP|GET]] или [[POST (HTTP)|POST]]; такой запрос называют ''«REST-запрос»''), а необходимые данные передаются в качестве [[параметр]]ов запроса<ref name="Fielding-Ch5" /><ref name=autogenerated1>{{cite web |url=http://tech.groups.yahoo.com/group/rest-discuss/message/6735 |title=Fielding discussing the definition of the REST term |publisher=Tech.groups.yahoo.com |accessdate=2013-11-28 |archive-date=2010-10-22 |archive-url=https://web.archive.org/web/20101022222125/http://tech.groups.yahoo.com/group/rest-discuss/message/6735 |deadlink=no }}</ref>.
@@ Строка 25: / Строка 25: @@
 == Требования к архитектуре REST ==
-Существует '''шесть''' обязательных ограничений для построения распределённых REST-приложений по [[Филдинг, Рой|Филдингу]]<ref name="Fielding-Ch5" /><ref name="SOAwithREST">{{книга|автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|часть=5.1|заглавие=SOA with REST|издательство=Prentice Hall|год=2013|isbn=978-0-13-701251-0}}</ref>.
+Существует '''пять''' обязательных<ref name="SOA with REST">{{книга |заглавие=SOA with REST |год=2013 |издательство=[[Prentice Hall]] |isbn=978-0-13-701251-0 |часть=5.1 |язык=und |автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian |ответственный=Thomas Erl}}</ref><ref name="Richardson 2007">{{Citation|last1=Richardson|first1=Leonard|title=RESTful Web service|year=2007|publisher=O'Reilly Media|isbn=978-0-596-52926-0|url=https://books.google.com/books?id=XUaErakHsoAC|first2=Sam|last2=Ruby|accessdate=2011-01-18|quote=The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation.}} {{Cite web |url=https://books.google.com/books?id=XUaErakHsoAC |title=Источник |access-date=2016-11-30 |archive-date=2012-02-19 |archive-url=https://web.archive.org/web/20120219072006/https://books.google.com/books?id=XUaErakHsoAC |deadlink=unfit }}</ref> ограничений для построения распределённых REST-приложений по [[Филдинг, Рой|Филдингу]]<ref name="Fielding-Ch5" /><ref name="SOAwithREST">{{книга|автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|часть=5.1|заглавие=SOA with REST|издательство=Prentice Hall|год=2013|isbn=978-0-13-701251-0}}</ref> и одно необязательное.
-Выполнение этих ограничений обязательно для REST-систем<ref name="SOA with REST">{{книга |заглавие=SOA with REST |год=2013 |издательство=[[Prentice Hall]] |isbn=978-0-13-701251-0 |часть=5.1 |язык=und |автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian |ответственный=Thomas Erl}}</ref><ref name="Richardson 2007">{{Citation|last1=Richardson|first1=Leonard|title=RESTful Web service|year=2007|publisher=O'Reilly Media|isbn=978-0-596-52926-0|url=https://books.google.com/books?id=XUaErakHsoAC|first2=Sam|last2=Ruby|accessdate=18 January 2011|quote=The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation.}} {{Wayback|url=https://books.google.com/books?id=XUaErakHsoAC |date=20120219072006 }}</ref>. Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надёжность.
+Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надёжность.
 Если сервис-приложение нарушает ''любое'' из этих ограничительных условий, данную систему нельзя считать REST-системой<ref name="Fielding-Ch5" />.
@@ Строка 43: / Строка 43: @@
 === 3. Кэширование ===
 {{Нет источников в разделе|дата=2017-03-16}}
-Как и во [[Всемирная паутина|Всемирной паутине]], клиенты, а также промежуточные узлы, могут выполнять [[кэширование]] ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно частично или полностью устранить некоторые клиент-серверные взаимодействия, ещё больше повышая производительность и масштабируемость системы.
+Как и во [[Всемирная паутина|Всемирной паутине]], клиенты, а также промежуточные узлы, могут выполнять [[кэширование]] ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно частично или полностью устранить некоторые проблемы клиент-серверного взаимодействия, ещё больше повышая производительность и масштабируемость системы.
 === 4. Единообразие интерфейса ===