Что же такого интересного в ASP.NET MVC?

Question

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, что означает, что вы можете использовать методы PUT или DELETE, используя формы браузера. Все, что вам нужно сделать, это добавить дополнительное скрытое поле, например:

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Поскольку REST неправильно понимается как URL, а не около ресурсов, стандартный интерфейс и гипермедиа .

Answer 4

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

Answer 5

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

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

1. Передача скрытого ввода в форме HTML, такой как _method.
2. Использование JavaScript для выполнения PUT или DELETE
3. Чтобы преодолеть некоторые брандмауэры, вам может понадобиться использовать заголовок 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 явно делает это.

Answer 6

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

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

Обратите внимание, что этот ответ будет устаревшим, как только выйдет так называемый ASP.NET vNext, в котором Web API и MVC будут объединены.

Answer 7

Руководитель проекта: «Давайте разработаем наш новый проект полностью RESTful !!!»

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

1. Несколько недель спустя на этапе разработки: «Сэр, нам нужно позволить клиенту иметь возможность обновлять несколько строк одновременно, поэтому нам нужно сделать обходной путь»

2. «Сэр, мне нужно получить только последний счет»

3. «Сэр, я должен передать номера и размер пейджинга!»

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