usando asp.net mvc para el punto final basado en REST

Question

Estoy buscando usar ASP.Net MVC como plataforma para un servicio basado en REST. Sé que WCF ha incorporado soporte para servicios REST; sin embargo, estoy buscando devolver varios tipos de datos dependiendo de la solicitud.

Me gustaría que el cliente solicite el tipo de contenido. Por lo tanto, si envían texto/html, por ejemplo, representaría mi modelo en Html; si solicitan texto/xml, devolverá xml. También podríamos hacer JSON.

¿Alguien ha visto algún problema con esto?

No utilizar WCF podría aumentar la complejidad del cliente al llamar al servicio, ya que no podrán generar automáticamente un proxy; sin embargo, en mi caso, los clientes serán el navegador que solicite html, o las bibliotecas del cliente de Java que procesen el xml.

Como no utilizamos WCF, debemos asegurar el servicio; sin embargo, estoy pensando que podemos hacer esto usando la autenticación de formularios.

El beneficio de esto es que no importa qué tipo de datos que el cliente está solicitando que todo va a través de los mismos controladores/modelos etc ...

Answer 1

Después de leer la publicación de Haack, sobre el uso de extensiones para indicar el tipo de contenido, creo que será mejor que inhabilite el encabezado Aceptar. Parece que me queda más descanso, aunque me ha sido un poco más difícil encender un navegador y probar tu url.

Paso juntos un pequeño artículo de blog sobre cómo hacer esto y usando un ModelBinder para abstraer el HttpContext de su controlador: http://jberke.blogspot.com/2009/03/aspnet-mvc-model-binder.html.

Además, en respuesta al comentario de opción de Troy, estaba usando la vista para representar Xml de mi modelo. Esto me permitió tener diferentes formatos xml para el mismo modelo. Lo cual tiene sentido. ¿Qué ocurre si necesita admitir el control de versiones o diferentes formatos para diferentes clientes? No me gusta la idea de que el marco represente automáticamente nada.

Answer 2

Es posible que desee echar un vistazo a esta entrada del blog y la siguiente discusión de Phil Haack:

http://haacked.com/archive/2009/01/06/handling-formats-based-on-url-extension.aspx

Su código utiliza la extensión del archivo solicitado (.html, .json, .xml) para determinar la salida, pero sólo podía utilizar la misma facilidad Accept-Encoding (o ambos).

Nota: Dejé un comentario en la publicación de Phil y sigo teniendo la firme convicción de que se deben requerir acciones para "participar" en los métodos de reproducción que admiten. Con la representación HTML, usted controla la cantidad de viewdata que se muestra al usuario final. La representación XML/JSON probablemente represente todo lo que pase a los datos de vista, independientemente de si pretende que sea públicamente visible o no.

Answer 3

La solución de Haack ciertamente no es la mejor manera de hacerlo, aunque es un buen punto de partida.

Para principiantes, si está trabajando con Entity Framework (o decide cambiar de Linq a SQL en una fecha posterior) JsonResult se romperá porque no puede serializar gráficos de objetos con referencias circulares (normalmente la mayoría de los modelos de datos). En segundo lugar, expone múltiples puntos finales para el mismo recurso.

La forma correcta de hacerlo es mirar el encabezado HTTP X-Requested-With para determinar si se trata de una solicitud XHR. O Content-Type: text/xml solicitud de encabezado para XML.

Le recomendaría que instale el complemento de Firefox para REST testing que simula las solicitudes de XHR. El plugin Tamper Data y algunos otros permiten un mayor control para probar/depurar. WFetch es una herramienta de solicitud HTTP sin formato que también es esencial para las pruebas y la depuración.

He escrito JSON/POX action filter por hacer esto. Solo necesita decorar sus clases o métodos con el atributo [JsonPox] y se expondrán automáticamente como JSON o XML dependiendo del cliente.