Convenciones de nomenclatura de MVC para acciones de JSON

¿Qué convención de nomenclatura se recomienda cuando se escribe una aplicación MVC que tiene rutas de acceso directo y JSON a los datos requeridos?Convenciones de nomenclatura de MVC para acciones de JSON

Por ejemplo, supongamos que el usuario de su sitio tiene "Cosas". Deberían poder ir a una página para ver sus cosas, pero también necesitamos una forma de retirar esas cosas como JSON en otras páginas. He podido pensar en varias opciones pero no estoy lo suficientemente interesado en ninguno de ellos para proceder. Esto es lo que tengo:

/cosas/lista de para la interfaz de usuario, /JSON/cosas para JSON - esto requeriría una JsonController que terminar sirviendo diferentes tipos de objetos, frustrando con ello cualquier posibilidad de separación de entidades antes de siquiera comenzar.
/cosas/lista de para la interfaz de usuario, /cosas/lista/JSON JSON para - probablemente mi opción preferida por el momento, pero requiere encordado magia (aunque sólo "json"). Además, si también necesita una firma de acción (ID de cadena) para tomar algunos parámetros de filtro o similares, entonces tiene la opción de agregar una ruta adicional o realizar una división de cadenas sucia.
/account/myThings para la interfaz de usuario, /cosas/ lista de JSON - un poco más limpia, pero podría no ser siempre un controlador relevante que podría servir a las "cosas" de. Además, estás mezclando entidades de nuevo.

Todo y cualquier sugerencia bienvenida, gracias!

Fuente

2009-06-06 tags2k

Mire mi respuesta en [Action Naming Convention] (http://stackoverflow.com/questions/118474/action-naming-convention/38994001#38994001). Espero que esto ayude ... –

Podría decirse que los nombres de ruta podrían ser todos iguales. Puede examinar el encabezado para el tipo MIME de la respuesta deseada de su cliente Aceptar, y luego regresar a una conclusión acertada sobre la base de lo que se encuentra allí:

application/json: JSON Ver
text/xml: XML Ver
text/plain, text/html: JSP Ver

Navegadores establece este campo en hTML; sus clientes JSON simplemente establecerían este campo según corresponda.

Fuente

2009-06-06 12:15:47

Estoy de acuerdo. Esto es para lo que está diseñada la negociación de contenido HTTP. Recomendaría definir sus propios tipos de mime para que pueda versionar sus formatos de datos JSON. Algo así como application/vnd.mycorp.myformat-1.0 + json. De esta forma, cuando algo cambia en su formato, puede cambiarlo a application/vnd.mycorp.myformat-1.1 + json (para un cambio compatible con versiones anteriores) o application/vnd.mycorp.myformat-2.0 + json (para un dispositivo incompatible hacia atrás) cambio). – Nat

Brillantemente elegante, gracias! La función $ .postJSON jQuery que estoy usando en mi UI ya envía los encabezados correctos, ¡así que esto es perfecto! – tags2k

Es muy poco probable que alguien marque como favorito una URL que solicite JSON, así que creo que no es tan importante mantener la URL como limpia. También es probable que se genere programáticamente, no se ingrese manualmente. Teniendo esto en cuenta, consideraría agregarlo como un parámetro de consulta.

/things/list -- HTML 
/things/list?format=json -- JSON

esto no va a romper sus URL si tiene parámetros de identificación o necesita otros parámetros. También podría funcionar con POST y GET.

/things/1 -- HTML for "thing 1" 
/things/1?format=json -- JSON for "thing 1"

Fuente

2009-06-06 12:21:39 tvanfosson

que utilizan la convención de

/things/list -- HTML 
/things/_listpage -- AJAX

La regla es que todas las acciones AJAXed/puntos de vista tienen un subrayado inicial. Esto me dice que nunca se llaman alto nivel, y generalmente no tienen una página maestra asociada. En este caso, mantengo la acción bajo el mismo controlador para compartir cualquier lógica asociada.

Normalmente, en la vista de lista me gustaría tener un

<% RenderAction("_listpage", "things", new {page = ViewData["CURRENT_PAGE"]}); %>

Fuente

2009-06-06 14:00:17 RedFilter

-1

recomendaría una variación leve/elaboración a la sugerencia de @RedFilter

/things/list -- HTML 
/things/_list -- return HTML help and examples (more for you than them). 
/things/_list/schema -- schema info 
/things/_list/json -- JSON format 
/things/_list/xml -- XML format 
/things/_list/csv -- csv format 
/things/_list/tab -- tab deliminated format 
/things/_list/wdsl -- implemented soap web service

etc .. siento que es más extensible . Parece aterrador, pero es fácil pasar los contenidos de los datos a través de un decorador en función del formato solicitado, lo que permite disponer de una gran cantidad de formatos de archivos con solo unas pocas líneas de código.

Aquí está un ejemplo conceptual crudo:

public ActionResult _list(string id) 
{ 
    string data = ""; 
    DataTable oDataTable = this.oDAO.Get("list"); // pretend data retrieval 

    try{ 
     if(!String.IsNullOrEmpty(id)){ 
      data = this.oDecorator.FormatData(id,oDataTable); 
      this.ContentTypeChange(id); // change application handler 
     }else{ 
      data = this.GetHelp("_list"); 
     }   
    }catch{} 
    ViewData["data"] = data; 
    return View(); 
}

... ayuda puede haber más de una lista de características, ejemplos técnicos, o como se quiera. Por supuesto, puede comenzar con solo tener JSON nativo y agregar más formatos de datos a su decorador a medida que crecen los requisitos, lo que es bueno. Para muchos de mis proyectos, comienza como un json rest puro de AJAX y tiende a florecer en otros formatos que se necesitan en función de la popularidad del sitio, por lo que he encontrado esto lo suficientemente robusto como para usar en una configuración empresarial para proyectos más pequeños que a menudo crecen grande.

Fuente

2014-02-04 08:11:03 Dave

Convenciones de nomenclatura de MVC para acciones de JSON

Respuesta

Cuestiones relacionadas