paginas - ¿Qué tiene de RESTful sobre ASP.NET MVC?

razor pages que es

Question

REST ha sido una palabra de moda popular durante los últimos años (más o menos) y cuando se lanzó ASP.NET MVC, todos relataban REST con ASP.NET MVC. También me enamoré del bullicio y de la falta de mi conocimiento, mi comprensión de REST fue simplemente justa:

REST = SEO / URL fáciles de usar

Pero es mucho más. Y cuanto más aprendo sobre REST, menos relaciono ASP.NET MVC con él. Por supuesto, está mucho más cerca de REST que WebForms. Entonces, la verdad es todo lo contrario:

REST ≠ SEO / URL amigables para el usuario

Y tener su ruta predeterminada definida como controller/action/id definitivamente no es RESTful.

Déjame explicar mi problema con esta comprensión.

Si ASP.NET MVC fuera RESTful, no tendríamos la ruta predeterminada definida como:

controller/action/id

mas bien

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

Entonces, en lugar de tener (también proporcionando el método HTTP con la ruta de solicitud):

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

debería ser (método HTTP provisto aquí también)

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

Ahora eso sería RESTful. Lo bueno es que esto es realmente posible. Y si lo hiciera completamente RESTful, también significaría que tendría que usar Ajax porque los métodos PUT y DELETE no se pueden hacer con solicitudes de solo navegador (esto no es completamente cierto ¹ ). Así que las aplicaciones modernas de Ajax pueden ser completamente RESTful.

Ajax es tecnología de cliente y realmente no tiene nada que ver con ASP.NET MVC. El hecho es que ASP.NET MVC se puede hacer como una aplicación completamente RESTful. Los medios para lograrlo (Ajax) no son importantes. (gracias a Darin Dimitrov)

La pregunta principal

¿Por qué consideramos a ASP.NET MVC como un marco RESTful, especialmente relacionando su enrutamiento de URL con este? ¿Por qué no definieron la ruta de URL predeterminada para aplicar RESTfulness? No busco respuestas argumentativas, sino las que realmente responden a la pregunta: ¿cómo esta relación cobró vida? Tal vez todavía no soy lo suficientemente sabio y todavía tomo esto como la falta de mi conocimiento sobre ambos.

¹ Información actualizada

En realidad, no tiene que usar Ajax para implementar una arquitectura completamente REST. Asp.net MVC admite (desde la versión 2) la anulación de método HTTP, lo que significa que puede emitir métodos PUT o DELETE utilizando formularios de navegador. Todo lo que tienes que hacer es agregar un campo oculto adicional como:

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

El framework Asp.net MVC podrá entender dicha solicitud POST como una solicitud DELETE y el selector de método de acción HttpDeleteAttribute también lo entenderá como una solicitud de eliminación. Método HTTP sobreescribiendo FTW!

Answer 1

Creo que mucho del zumbido tuvo más que ver con cuán poco resquilibrante era la pila web de .NET antes de MVC y cuánto más fácil fue MVC para construir aplicaciones RESTful en la plataforma .NET que cualquier capacidad RESTful en particular de ASP.NET MVC.

Answer 2

Esta pregunta está ligeramente anticuada, y la respuesta en este momento (2014-08) sería esta: ASP.NET MVC permite esquemas RESTful URL pero no está diseñado de manera que este sea el predeterminado. En cambio, el pozo del éxito con ASP.NET MVC es un estilo de controlador + acción más tradicional de MVC.

La forma de ASP.NET de escribir servicios RESTful ahora sería ASP.NET Web API. Esto hace que sea aún más fácil crear un esquema de URL RESTful mediante el uso de convenciones de nombres de métodos que coincidan con los verbos HTTP.

Tenga en cuenta que esta respuesta estará desactualizada una vez que lo que actualmente se llama ASP.NET vNext esté fuera, en el que la API web y el MVC se unan en uno.

Answer 3

No hay nada que le impida tener rutas como resource/id con los métodos HTTP GET / PUT / POST / DELETE en ASP.NET MVC. No es la configuración predeterminada de las rutas, pero puedes hacerlo.

EDITAR (MLaritz - Agregar el comentario de Darin): ASP.NET MVC es una tecnología del lado del servidor que le permite exponer las URL RESTful. La forma en que se consumen no importa. Usted preguntó por qué ASP.NET MVC se considera tecnología RESTFul y la respuesta es porque puede exponer fácilmente las URL RESTFul para el consumo, es así de simple.

Answer 4

No hay un estilo de URI que haga que una API sea tranquila.

Usted preguntó: "¿Por qué consideramos ASP.NET MVC como un marco RESTful especialmente relacionando su enrutamiento de URL a él?"

Debido a que se entiende mal REST, se trata de URL en lugar de recursos, una interfaz estándar e hipermedia .

Answer 5

Project Manager: "¡Desarrollemos nuestro nuevo proyecto completamente RESTful!"

Otros programadores gritan: "¡YAyyyyyy!"

1. Pocas semanas después, en la etapa de desarrollo: "Señor, tenemos que permitir que el cliente pueda actualizar varias filas al mismo tiempo, por lo tanto, tenemos que hacer una solución".

2. "Señor, necesito obtener solo la última factura"

3. "¡Señor, debo pasar los números y el tamaño de la megafonía!"

gorrón. ¿Por qué no todos regresamos a XML RPC?

Answer 6

Solo pensé en contribuir a la discusión de REST sobre el uso de PUT y DELETE.

En general, en REST y otros marcos RESTful, el problema de PUT y DELETE no se resuelve haciendo URL como resource/create o resource/delete . Por el contrario, el verbo se tuneliza a través de POST por:

1. Pasar una entrada oculta en un formulario HTML como _method .
2. Usar JavaScript para hacer el PUT o ELIMINAR
3. Para superar algunos firewalls, es posible que deba usar el encabezado HTTP X-HTTP-Method-Override .

Esta es una solución general para el problema de los métodos HTTP.

No se me informó acerca de ASP.Net para decir por qué no tomaron ese camino, pero una URL como /product/delete/1 no proporciona un recurso RESTful.

Editar : Un poco de aclaración sobre lo que es REST parece ser necesario. De la boca del caballo :

Una API REST no debe contener ningún cambio en los protocolos de comunicación además de completar o corregir los detalles de los bits de los protocolos estándar, como el método PATCH de HTTP o el campo del encabezado Link. Las soluciones provisionales para implementaciones rotas ( como aquellos navegadores lo suficientemente estúpidos como para creer que HTML define el conjunto de métodos de HTTP ) deben definirse por separado, o al menos en apéndices, con la expectativa de que la solución sea eventualmente obsoleta. [La falla aquí implica que las interfaces de recursos son específicas del objeto, no genéricas].

Énfasis mío REST no se define como el uso de los cuatro métodos HTTP. Ni siquiera está definido como usar HTTP. Necesita un protocolo de comunicación con la capacidad de seguir hipervínculos. Y usa ese protocolo, con las definiciones adecuadas agregadas sin violar el protocolo.

En el caso de HTTP, el uso de soluciones para navegadores que no implementan PUT y DELETE está explícitamente permitido . El método Rails en el punto 1 claramente lo hace.

Answer 7

Este enlace puede iluminarlo en su búsqueda ... en pocas palabras, puede tener Urls como usted describe, al menos con MVC 2.