Вот мой основной план ОТДЫХА. Я попытался продемонстрировать мышление каждого из компонентов в архитектуре RESTful, чтобы понимание концепции было более интуитивным. Надеюсь, это поможет демистифицировать REST для некоторых людей!
REST (Передача репрезентативного состояния) - это архитектура проекта, которая описывает, как сетевые ресурсы (т.е. узлы, которые совместно используют информацию) проектируются и адресуются. В целом, архитектура RESTful делает так, чтобы клиент (запрашивающий компьютер) и сервер (отвечающий компьютер) могли запрашивать чтение, запись и обновление данных, при этом клиенту не нужно знать, как работает сервер, и сервер может пройти назад без необходимости знать что-либо о клиенте. Хорошо, круто ... но как мы можем это сделать на практике?
Наиболее очевидным требованием является наличие какого-либо универсального языка, чтобы сервер мог сообщить клиенту, что он пытается сделать с запросом, и чтобы сервер ответил.
Но чтобы найти какой-либо конкретный ресурс и затем сообщить клиенту, где он находится, необходим универсальный способ указания ресурсов. Это где универсальные идентификаторы ресурсов (URI) приходят; это в основном уникальные адреса для поиска ресурсов.
Но архитектура REST на этом не заканчивается! Хотя вышеперечисленное удовлетворяет основные потребности того, что мы хотим, мы также хотим иметь архитектуру, которая поддерживает большой объем трафика, поскольку любой данный сервер обычно обрабатывает ответы от ряда клиентов. Таким образом, мы не хотим перегружать сервер, заставляя его запоминать информацию о предыдущих запросах.
Поэтому мы налагаем ограничение на то, что каждая пара запрос-ответ между клиентом и сервером независима, то есть сервер не должен ничего помнить о предыдущих запросах (предыдущих состояниях взаимодействия клиент-сервер). ) ответить на новый запрос. Это означает, что мы хотим, чтобы наши взаимодействия не имели состояния.
Чтобы еще больше облегчить нагрузку на наш сервер от повторения вычислений, которые недавно были выполнены для данного клиента, REST также позволяет кэшировать. По сути, кэширование означает создание снимка исходного ответа, предоставленного клиенту. Если клиент делает тот же самый запрос снова, сервер может предоставить клиенту моментальный снимок, а не повторять все вычисления, которые были необходимы для создания начального ответа. Однако, поскольку это моментальный снимок, если моментальный снимок не истек - сервер заранее устанавливает время истечения - и ответ был обновлен с момента первоначального кэша (т. Е. Запрос дал бы ответ, отличный от кэшированного ответа) клиент не увидит обновления до тех пор, пока не истечет срок действия кеша (или кеш не будет очищен) и ответ не будет обработан с нуля.
Последнее, что вы часто будете здесь о архитектурах RESTful, - это их многоуровневость. На самом деле мы уже неявно обсуждали это требование в нашем обсуждении взаимодействия между клиентом и сервером. По сути, это означает, что каждый слой в нашей системе взаимодействует только с соседними слоями. Таким образом, в нашем обсуждении уровень клиента взаимодействует с уровнем нашего сервера (и наоборот), но могут существовать и другие уровни сервера, которые помогают основному серверу обрабатывать запрос, с которым клиент не связывается напрямую. Скорее сервер передает запрос по мере необходимости.
НетЕсли все это звучит знакомо, то отлично. Протокол передачи гипертекста (HTTP), который определяет протокол связи через World Wide Web, является реализацией абстрактного понятия архитектуры RESTful (или экземпляром класса REST, если вы фанат ООП, как я). В этой реализации REST клиент и сервер взаимодействуют через GET, POST, PUT, DELETE и т. Д., Которые являются частью универсального языка, и ресурсы можно указывать с помощью URL.