Что такое RESTful о ASP.NET MVC?

REST был таким популярным модным словом за последние пару лет (или около того), и когда ASP.NET MVC выкатился, все связывали REST с ASP.NET MVC. Я также упал на шум и из-за отсутствия моих знаний, мое понимание REST было просто:

REST = SEO/дружественные пользователю URL

Но это намного больше. И чем больше я узнаю о REST, тем меньше я связываю ASP.NET MVC с ним. Это, конечно, гораздо ближе к REST, чем к WebForms. Итак, правда на самом деле совершенно противоположна:

REST ≠ SEO/дружественные пользователю URL

И если ваш маршрут по умолчанию, определенный как controller/action/id, определенно не RESTful.

Позвольте мне объяснить мою проблему с этим пониманием.

Если ASP.NET MVC был RESTful, у нас не было бы маршрута по умолчанию, определенного как:

controller/action/id

а скорее

resources/id  /* that would have to use HTTP methods GET/PUT/POST/DELETE */

Итак, вместо того, чтобы иметь (также предоставляющий HTTP-метод с запросом):

/product/index/1  /* GET */
/product/create   /* POST */
/product/delete/1 /* POST */
/product/update/1 /* POST */

он должен быть (HTTP-метод также предоставлен здесь)

/products/1  /* GET */
/products    /* POST */
/products/1  /* DELETE */
/products/1  /* PUT */

Теперь это будет RESTful. Хорошо, что это действительно возможно. И если вы сделаете это полностью RESTful, это также означало бы, что вы должны использовать Ajax, потому что методы PUT и DELETE не могут быть выполнены с помощью запросов только для браузера (это не совсем верно ¹). Таким образом, современные приложения Ajax могут быть полностью RESTful.

Ajax - это клиентская технология и на самом деле не имеет ничего общего с ASP.NET MVC. Факт в том, что ASP.NET MVC может быть выполнен как полностью RESTful-приложение. Средство его достижения (Ajax) не имеет значения. (спасибо Дарину Димитрову)

Основной вопрос

Почему мы рассматриваем ASP.NET MVC как структуру RESTful, особенно связанную с его маршрутизацией URL-адресов? Почему они не задали маршрут URL по умолчанию для обеспечения RESTfulness? Я не ищу аргументативных ответов, но те, которые на самом деле отвечают на вопрос - как это отношение воплотилось в жизнь... Возможно, я по-прежнему недостаточно мудр и все еще воспринимаю это как недостаток моих знаний об обоих.

¹ Обновленная информация

На самом деле вам не нужно использовать Ajax для полной реализации архитектуры RESTful. Asp.net MVC поддерживает (начиная с версии 2) метод HTTP overriding, то есть вы можете выдавать методы PUT или DELETE с использованием форм браузера. Все, что вам нужно сделать, это добавить дополнительное скрытое поле, например:

<input type="hidden" name="X-HTTP-Method-Override" value="DELETE" />

Структура MVC Asp.net сможет понять такой запрос POST как запрос DELETE, а селектор действия HttpDeleteAttribute также будет понимать его как запрос на удаление. Метод HTTP, переопределяющий FTW!

Ответ 1

Ничего не мешает вам использовать такие маршруты, как resource/id, с помощью HTTP-методов GET/PUT/POST/DELETE в ASP.NET MVC. Это не настройка маршрутов по умолчанию, но вы можете это сделать.

EDIT (MLaritz - добавление комментария Дарина): ASP.NET MVC - это серверная технология, позволяющая выявлять URL-адреса RESTful. То, как они потребляются, не имеет значения. Вы спросили, почему ASP.NET MVC считается технологией RESTFul, и ответ заключается в том, что вы можете легко разоблачить URL-адреса RESTFul для потребления, это так просто.

Ответ 2

Я думаю, что много шума было связано с тем, как un-RESTful веб-стек .NET был до MVC и насколько проще MVC сделал его для создания RESTful-приложений на платформе .NET, чем любые особенности RESTful ASP.NET MVC имеет.

Ответ 3

Не существует стиля URI, который делает API незабываемым.

Вы спросили: "Почему мы рассматриваем ASP.NET MVC как структуру RESTful, особенно связанную с его маршрутизацией URL-адресов?"

Потому что REST неправильно понимают, что речь идет о URL-адресах, а не о ресурсах, стандартном интерфейсе и гипермедиа.

Ответ 4

Эта ссылка может просветить вас в вашем квесте... Короче говоря, у вас могут быть такие URL-адреса, которые вы описываете - по крайней мере, с MVC 2.

Ответ 5

Я просто подумал внести свой вклад в обсуждение REST об использовании PUT и DELETE.

В общем случае в REST и других RESTful-системах проблема PUT и DELETE не решается путем создания URL-адресов, таких как resource/create или resource/delete. Скорее, глагол туннелируется через POST:

Передача скрытого ввода в формате HTML, например _method.
Использование JavaScript для выполнения PUT или DELETE
Чтобы преодолеть некоторые брандмауэры, вам может понадобиться использовать заголовок HTTP X-HTTP-Method-Override.

Это общее решение для проблемы HTTP-методов.

Мне не сообщили об ASP.Net, чтобы сказать, почему они этого не сделали, но такой URL, как /product/delete/1, не предоставляет ресурс RESTful.

Изменить. Немного разъяснения о том, что такое REST, кажется необходимым. Из уст лошади:

API REST не должен содержать никаких изменений в протоколах связи, кроме заполнения или исправления деталей недописанных битов стандартных протоколов, таких как HTTP-метод PATCH или поле заголовка ссылки. Обходные пути для неработающих реализаций (, такие как те браузеры, которые достаточно глупы, чтобы полагать, что HTML задает метод HTTP-методов), должны быть определены отдельно или, по крайней мере, в приложениях, с ожиданием, что обходной путь в конечном итоге будет устаревшим. [Сбой здесь означает, что интерфейсы ресурсов являются объектно-ориентированными, а не универсальными.]

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

В случае HTTP явно разрешены обходные пути для браузеров, которые не реализуют PUT и DELETE. Метод Rails в пункте 1 явно делает это.

Ответ 6

Этот вопрос слегка устарел, и ответ прямо сейчас (2014-08) будет следующим: ASP.NET MVC допускает схемы URL RESTful, но не разработан таким образом, что это значение по умолчанию. Вместо этого ядро успеха с ASP.NET MVC является более традиционным типом Controller + Action для MVC.

В настоящее время ASP.NET для написания сервисов RESTful будет ASP.NET Web API. Это упрощает создание схемы URL RESTful с использованием соглашений об именах методов, соответствующих HTTP-глаголам.

Обратите внимание, что этот ответ будет устаревшим после того, как вызывается в настоящее время ASP.NET vNext, в котором веб-API и MVC включены в один.

Ответ 7

Менеджер проекта: "Пусть новый проект полностью разработан RESTful!!!"

Другие программисты кричат: "YAyyyyyy!!!"

Несколько недель спустя на стадии разработки: "Сэр, мы должны позволить клиенту иметь возможность обновлять несколько строк одновременно, поэтому нам нужно сделать обходное решение"
"Сэр, мне нужно получить только последний счет"
"Сэр, я должен передать номера и размер пейджинга!"

облом. почему бы нам не вернуться к XML RPC