Это RESTful?

Question

У меня есть приложение Rails, которое должно представлять значения из базы данных в виде веб-службы - поскольку я использую Rails 2.x, я использую REST (или, по крайней мере, пытаюсь). Предполагая, что моим ресурсом являются бананы, для которых я хочу раскрыть несколько суб-характеристик, рассмотрим это:

 - /banana          -> give a summary of the first 10 bananas, in full (all characteristics)
 - /banana/?name=<name>         -> give all characteristics for banana named <name>
 - /banana/?number=<number>         -> give all characteristics for banana number <number>
 - /banana/?name=<name>/peel          -> give peel data for banana named <name>
 - /banana/?number=<number>/length         -> give length data for banana number <number>

Я не хочу искать идентификатор, только имя или номер . И у меня есть около 7 подчиненных характеристик, чтобы выставить Это RESTful?

Спасибо за любые отзывы!

Answer 1

То, о чем говорит Ванфриден, - это нечто, называемое Гипермедиа как двигатель состояния приложения (HATEOAS) - центральное ограничение REST, определенное Fielding.

Короче говоря, клиенты приложений REST никогда не создают сами URI. Вместо этого они следуют URI, предоставленным приложением. Таким образом, шаблоны URI, такие как те, о которых вы спрашиваете, в лучшем случае не имеют отношения к делу. Вы можете настроить их на соответствие системе, но REST ничего не говорит о том, как должны выглядеть ваши URI. Вы можете, если хотите, организовать это так, чтобы каждый ресурс в вашей системе был доступен с http://example.com/{hash}.

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

Проблема понимания приложений, управляемых гипермедиа, заключается в том, что почти никто не реализует и не документирует свои системы "RESTful" таким образом.

Это может помочь подумать о взаимодействии человека и сервера через браузер. Человек знает только о контенте и ссылках, которые сервер предоставляет через браузер. Вот как должна быть построена система RESTful. Если ваши ресурсы не предоставляют ссылки, возможно, они не RESTful.

Преимущество состоит в том, что если вы хотите изменить свою систему URI, например, чтобы выставить атрибут Banana "Peel" через параметр запроса вместо вложенного URL-адреса, вы можете сделать это в любое время и без кода клиента. необходимо изменить, потому что они не создают ссылки для себя.

В качестве примера системы, в которой используется ограничение на основе гипертекста в REST, ознакомьтесь с Sun Cloud API .

Answer 2

Я бы использовал это:

• / банан
• / банан / мля
• / банан / 123
• / банан / бла / кожура (и / банан / 123 / кожура)
• / банан / бла / длина (и / банан / 123 / длина)

Во-первых, обычной практикой для ReSTful URI является / object_name / id / verb, причем некоторые из них отсутствуют (но в таком порядке). Конечно, это не требуется и не ожидается.

Если все ваши имена не состоят из цифр, вам не нужно явно указывать name в / banana / name / blah. На самом деле, во всяком случае, было бы лучше иметь id в качестве идентификатора: / banana / id / 123 / peel. Надеюсь, это поможет.

Answer 3

Параметры должны использоваться только для отправки формы.

Кроме того, схемы именования URI совершенно не связаны с REST. Смысл REST состоит в том, чтобы сделать связанные ресурсы обнаруживаемыми через гипертекст, а не внеполосные соглашения и только из ограниченного числа точек входа. Таким образом, ваша / bananas / точка входа может предоставить сводную информацию для 10 бананов, но она также должна предоставить URI для каждого из ресурсов данных этих бананов, а также URI, чтобы получить сводку для следующих 10 бананов. Все остальное просто RPC.

Answer 4

Более подходящей формой для маршрута в URL, содержащем строку запроса, является форма множественного числа, поскольку возможно, что в результате будет возвращено несколько элементов. В этом случае бананы, как и бананы? Color = yellow, звучат более уместно. С другой стороны, форма банана в единственном числе, такая как banana / 123, удобна при извлечении представления конкретного ресурса, когда известен его идентификатор и строка запроса не требуется.

Answer 5

В REST рекомендуется не использовать параметры запроса, поскольку параметры запроса не принадлежат URL-адресу, а в REST все ресурсы должны быть адресуемыми через URL-адрес.

В вашем примере / banana /? Name = name должно быть / banana / name , поскольку вы ссылаетесь на конкретный ресурс.

Даже я думаю, что / banana /? Number = число / length не подходит для стиля REST, потому что вы выбираете атрибут через URL, когда вы должны получить все состояние с помощью / banana / имя . Разница может быть в / customer / 1024 / address, чтобы получить адресную запись Customer 1024.

НТН.