Convenzioni di denominazione MVC per azioni JSON

Question

Quale convenzione di denominazione è consigliata quando si scrive un'app MVC con percorsi sia front-end che JSON per i dati richiesti?

Ad esempio, supponiamo che l'utente del tuo sito abbia "Cose". Dovrebbero essere in grado di andare su una pagina per vedere le loro cose, ma abbiamo anche bisogno di un modo per rimandare quelle cose come JSON su altre pagine. Sono stato in grado di pensare a diverse opzioni, ma non sono abbastanza entusiasta su nessuna di esse per procedere. Ecco quello che ho:

1. /cose/Lista per l'interfaccia utente, /JSON/cose per JSON - ciò richiederebbe un JsonController che finirebbe per servire diversi tipi di oggetti, vanificando quindi ogni possibilità della separazione delle entità prima ancora che iniziamo.
2. /cose/Lista per l'interfaccia utente, /cose/list/JSON per JSON - probabilmente la mia opzione preferita in questo momento, ma richiede incordatura magia (anche se solo "json"). Inoltre, se hai bisogno anche di una firma di azione (id di stringa) per inserire alcuni parametri di filtro o simili, allora hai la possibilità di aggiungere una route aggiuntiva o eseguire una suddivisione delle stringhe sporca.
3. /account/myThings per l'interfaccia utente, /cose/lista per JSON - un po 'più pulita, ma ci potrebbero non essere sempre un controller rilevante che si possa servire le "cose" da. Inoltre, stai mescolando di nuovo le entità.

Tutti e qualsiasi suggerimento benvenuto, grazie!

Answer 1

Probabilmente i nomi dei percorsi potrebbero essere tutti uguali. È possibile esaminare l'intestazione per il mime-type di risposta desiderata del vostro cliente accetta, e quindi restituire una visione adeguata in base a quello che si trova lì:

• application/json: JSON View
• text/xml: XML vista
• text/plain, text/html: JSP View

browser impostare questo campo in HTML; i tuoi client JSON dovrebbero semplicemente impostare questo campo come appropriato.

Answer 2

È altamente improbabile che qualcuno inserisca in un segnalibro un URL che richiede JSON, quindi penso che non sia così importante mantenere l'URL pulito. È anche probabile che venga generato a livello di codice, non inserito manualmente. Considerati questi, prenderei in considerazione l'aggiunta come parametro di query.

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

Questo non interromperà gli URL se si dispone di parametri ID o di altri parametri. Potrebbe funzionare anche con POST e GET.

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

Answer 3

io uso la convenzione di

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

La regola è che tutte le azioni ajaxed/Vista hanno una sottolineatura iniziale. Questo mi dice che non vengono mai chiamati di primo livello e di solito non hanno una pagina master associata. In questo caso, mantengo l'azione sotto lo stesso controller per condividere qualsiasi logica associata.

Tipicamente nella vista elenco avrei un

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

Answer 4

mi sento di raccomandare una leggera variazione/elaborazione al suggerimento da @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 

ecc .. Mi sento che è più estensibile . Sembra spaventoso, ma è facile passare il contenuto dei dati attraverso un decoratore basato sul formato richiesto, rendendo disponibile un'intera serie di formati di file con praticamente poche righe di codice.

Ecco un esempio grezzo concettuale:

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(); 
} 

... aiuto può essere più di un elenco di caratteristiche, esempi tecnici, o quello che volete. Ovviamente puoi iniziare semplicemente con il JSON nativo e aggiungere altri formati di dati al tuo decoratore man mano che crescono le esigenze, il che è bello. Per molti dei miei progetti inizia come un puro json riposare da un AJAX e tende a sbocciare in altri formati che sono necessari in base alla popolarità del sito, quindi ho trovato questo abbastanza robusto da usare in un ambiente aziendale per progetti più piccoli che spesso crescono grande.