Что такое архитектура REST и как она реализована в Rails?

Ответ 1

Я думаю, что ваше понимание REST довольно хорошее. Это не должно быть сложнее, чем должно быть. Также @Surya очерчивает некоторые очень хорошие моменты.

Способ Rails сопоставляет методы HTTP с методами контроллера:

GET    => show
PUT    => update
POST   => create
DELETE => destroy

Два других ресурса/метода, которые рельсы обеспечивают именно:

resource/new  => new
resource/edit => edit

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

Если все пользователи были полностью осведомлены о ресурсах и достаточно умели с командной строкой, нам даже не понадобится HTML. Они могут просто curl в своих взаимодействиях с этими ресурсами:)

index просто упрощает работу с коллекциями. Он по-прежнему является четко определенным ресурсом и имеет уникальное представление, например /books. Как это обрабатывается на стороне сервера код не делает его RESTless (я только что сделал это, но его удивительный).

Ответ 2

Я бы начал с глава 5 диссертации Роя Филдинга. Существует несколько основных принципов:

• Ресурсы: ресурс может быть типичным для того, что вы предоставляете внешнему миру как часть вашего сервиса. Основное внимание уделяется идентификации ресурсов (например, Book, UserList, CalculateDistance).
• URI: предоставить каждому ресурсу идентификатор (например: example.com/books/7654)
• Равномерный интерфейс: используйте стандартные методы, такие как GET, PUT. POST, DELETE, HEAD, OPTIONS
• Представления: ресурс может иметь несколько представлений. Например, GET в книге может вернуть PDF-код этого содержимого книги, HTML-контента и, если на то пошло, даже GIF с обложкой книги и так далее. Представление представляет собой совокупность всех данных и разметки.
• Hypermedia: Этот, на мой взгляд, очень важный принцип. Внедрение этого принципа заставляет ваше приложение намного опережать обычные CRUD-подобные определения, в которые помещается стиль REST. HATEOAS - это акроним, который обозначает Hypermedia как двигатель состояния приложения. Когда вы нажимаете на ссылку или отправляете форму, вы меняете состояние приложения, которое происходит через гиперссылки (или гипермедиа). Между сервером и клиентом очень мало связей. Клиент перемещается через приложение через ссылки, предоставляемые сервером. (в блогосфере много дискуссий по этому принципу...) [Также посмотрите Restfulie]

Я недавно ответил на вопрос о хороших ресурсах, чтобы узнать REST, может быть полезным.

Я не знаком с Rails, поэтому не рассматриваю эту часть вопроса.

Ответ 3

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

REST (Репрезентативный перенос состояний) - это архитектура проектирования, в которой описывается, как спроектированы и решены сетевые ресурсы (то есть узлы, которые обмениваются информацией). В общем, архитектура RESTful делает это так, чтобы клиент (запрашивающая машина) и сервер (машина ответа) могли запрашивать чтение, запись и обновление данных без необходимости знать, как сервер работает и сервер может пройти он обратно, не нужно ничего знать о клиенте. Хорошо, круто... но как мы это делаем на практике?

• Наиболее очевидным требованием является наличие какого-либо универсального языка, чтобы сервер мог сообщить клиенту, что он пытается сделать с запросом, и для ответа сервера.

• Но чтобы найти какой-либо данный ресурс, а затем сообщить клиенту, где живет этот ресурс, должен быть универсальный способ указывать на ресурсы. В это место входят универсальные идентификаторы ресурсов (URI); они в основном уникальные адреса для поиска ресурсов.

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

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

• Чтобы еще больше снизить нагрузку на наш сервер из повторных вычислений, которые уже были недавно выполнены для данного клиента, REST также позволяет кэшировать. В основном, кэширование означает получение моментального снимка исходного ответа, предоставленного клиенту. Если клиент повторяет тот же запрос, сервер может предоставить клиенту снимок, а не повторить все вычисления, необходимые для создания начального ответа. Однако, поскольку это моментальный снимок, если моментальный снимок не истек - сервер заранее задает время истечения срока действия - и ответ был обновлен с момента первоначального кеша (т.е. Запрос дал бы другой ответ, чем кешированный ответ), клиент не будет видеть обновления до истечения срока действия кэша (или очистка кэша), и ответ снова будет показан с нуля.

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

Теперь, если все это звучит знакомо, тогда здорово. Протокол передачи гипертекста (HTTP), который определяет протокол связи через всемирную паутину, представляет собой реализацию абстрактного понятия архитектуры RESTful (или экземпляр класса REST, если вы фанатик ООП, как я). В этой реализации REST клиент и сервер взаимодействуют через GET, POST, PUT, DELETE и т.д., Которые являются частью универсального языка, и ресурсы могут указывать на использование URL-адресов.

Ответ 4

Как вы могли заметить, есть 4 действия HTTP, но для основных операций CRUD в типичном веб-приложении требуется 7 разных действий. Некоторые из них на самом деле ничего не делают (например, /new и :id/edit) и, таким образом, являются параллельными архитектуре REST. Также действие индекса не действует на ресурс, а скорее на набор ресурсов (таким образом, также уникальный URL-адрес).

Итак, основные 4 HTTP-действия сопоставляются с таким ресурсом:

• Карты GET для отображения → get /teams/:id
• Карты PUT для обновления → put /teams/:id
• УДАЛИТЬ карты для уничтожения → delete /teams/:id
• POST - это немного исключение, так как ресурс еще не существует, поэтому он сопоставляется с базой /teams

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

Ответ 5

Подобно/teams → для метода 'index'... /teams/new → для 'нового' метода и так далее на. Разве это не отходит от отдыха, который определяет, что каждый ресурс имеет один уникальный URI

Нет, это не отходит от REST, поскольку в отношении REST /teams и /teams/new находятся два разных ресурса.