REST Url Structure - Может ли идентификатор ресурса идти до контроллера?

Question

Стандартный шаблон для ASP.NET MVC (и MVC в целом) выглядит как {controller} / {action} / {id} , однако, над проектом, над которым я сейчас работаю, я Я не уверен, что это подходящая структура. Например, если бы у меня было приложение, которое управляло автомобилем, для меня было бы более разумно иметь следующую структуру:

  {car-rego}/{controller}/{action}/{data etc}

Это имеет смысл для меня, потому что автомобиль (обозначенный регистрационной табличкой) - это ресурс, над которым мы выполняем операции, а логическое разделение функций разделяется на контроллер и действие. Это приведет к URL-адресам, таким как:

/ESX-121/Power/On
/ESX-121/Speed/Set/100
/ESX-121/Speed/Current -- get the current speed (could be /ESX-121/Speed also)
/ESX-121/Turn/Left
/ESX-121/Speed/Set/90
/ESX-121/Power/Off

Если бы это следовало шаблону по умолчанию, это было бы что-то вроде ниже:

/Power/On/ESX-121
/Speed/Set/ESX-121/100
/Speed/Current/ESX-121 -- get the current speed (could be /Speed/ESX-121 also)
/Turn/Left/ESX-121
/Speed/Set/ESX-121/90
/Power/Off/ESX-121

Для меня первый вариант имеет гораздо больше смысла в том, что касается читаемого URL, а идентификатор ресурса находится в постоянном логическом месте. Например, / Speed ​​/ Set / ESX-121/100 подсказывает мне, что есть запас скорости типа с идентификатором ESX-121, который на самом деле не тот, операция выполняется на автомобиле.

Как вы собираетесь структурировать URL и связанные контроллеры и действия для таких случаев, как этот? Как вы думаете, это приемлемое решение или есть лучший способ структурирования?

Answer 1

С "философской" точки зрения есть большая проблема.

Вы, похоже, используете запросы GET для почти всего, например, для установки скорости. Идея, лежащая в основе REST, заключается в том, что доступ к ресурсу ESX-121 дает представление о его текущем состоянии, в вашем случае - скорости, направлении, если он включен и т. Д.

Размещение некоторого представления автомобиля по его URL эффективно изменит его текущее состояние. (Если вы используете XML для представления, например, вы можете опубликовать

<car><id>ESX-121</id><speed>100</speed><car>

чтобы изменить скорость. Под ASP.net MVC вы должны отправить форму для этого.

То, что вы пытаетесь сделать, - это применить способ моделирования службы SOAP (ориентированный на операции или глаголы) к службе REST, что на самом деле не является идеей.

Может быть трудно "получить" способ выполнения REST, и он может идти вразрез со всем, что вы делали, если вы использовали сервисы SOAP, но важно помнить об этих принципах.

Теоретически, ваш URL описывает ресурс, и единственные доступные операции выполняются через GET (чтение), POST (создание), PUT (создание или обновление), DELETE (удаление).

РЕДАКТИРОВАТЬ: Спасибо Марксиду за то, что он исправил меня в том, к чему должен соответствовать каждый глагол.

Answer 2

Помимо комментариев, указанных в посте выше, я думаю, что вполне нормально немного изменить структуру. (Но не используйте GET для обновления данных, как указано выше)

Возьмите, например, CMS, вы часто будете видеть следующую структуру:

{controller}/{id}/{action}
или
pages/about_the_company (действие по умолчанию является действием по умолчанию)
pages/about_the_company/edit (GET отобразит страницу редактирования, а POST выполнит обновление)

Конечно, в CMS контроллер будет по умолчанию установлен на pages, поэтому URL будет еще короче.

Answer 3

REST - это не чистые URI, а правильная семантика, привязанная к HTTP-методам GET, POST, PUT и DELETE.

GET должен использоваться только для безопасных идемпотентных операций, POST должен использоваться для создания или обработки, PUT должен использоваться для обновления существующего ресурса, а DELETE для (хмм) удаления ресурса.

Вы можете использовать некрасивые URI с большим количеством параметров «? И &», но при этом все равно можете начинать RESTful.

Теперь о ваших URI, хотя второй вариант может выглядеть хорошо, это способ написать «простой английский», используя язык, который не является английским. Во-первых, это может показаться хорошей идеей, но основная идея сделать URI читабельными в том, что клиент может играть с ними и открывать новые функции. Вот почему всегда лучше сохранять древовидную структуру вашего сайта / приложения в ваших URI.

См. Alertbox Джейкоба Нильсена о URL как UI для получения дополнительной информации по теме.

Answer 4

Если вы определяете какую-либо структуру именования URI, например "{car-rego} / {controller} / {action} / {data etc}" ", тогда ваш API не является REST. Это просто RPC. Вы не можете определить URI или соглашения об именах URI как часть REST API - это напрямую нарушает одно из ограничений архитектуры RESTful.

См. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven для получения дополнительной информации.