MVC-Namenskonventionen für JSON-Aktionen

Question

Welche Namenskonvention wird empfohlen, wenn Sie eine MVC-Anwendung schreiben, die sowohl Front-End- als auch JSON-Pfade zu den erforderlichen Daten enthält?

Nehmen wir zum Beispiel an, der Benutzer Ihrer Website hat "Dinge". Sie sollten in der Lage sein, auf eine Seite zu gehen, um ihre Sachen zu sehen, aber wir brauchen auch eine Möglichkeit, diese Dinge als JSON auf anderen Seiten zurückzubringen. Ich habe mir verschiedene Möglichkeiten ausdenken können, aber ich bin nicht scharf genug darauf, weiterzumachen. Hier ist, was ich habe:

1. /Dinge/Liste für UI, /json/Dinge für JSON - dies würde einen JsonController erfordern, die unterschiedlichen Arten von Objekten enden würde dienen, wodurch eine Chance zu besiegen der Trennung der Entitäten, bevor wir überhaupt beginnen.
2. /Dinge/Liste für UI, /Dinge/Liste/json für JSON - wahrscheinlich meine bevorzugte Option im Moment, aber erfordert Magie Bespannung (wenn auch nur "json"). Wenn Sie auch eine (String-ID-) Aktionssignatur zum Eingeben einiger Filterparameter oder Ähnlichem benötigen, haben Sie die Wahl, eine zusätzliche Route hinzuzufügen oder eine fehlerhafte String-Aufteilung durchzuführen.
3. /account/myThings für UI, /Dinge/Liste für JSON - etwas saubere, aber es möglicherweise nicht immer ein entsprechender Controller sein, dass Sie die „Dinge“ von dienen könnten. Außerdem mischen Sie wieder Entitäten.

Alle und alle Anregungen willkommen, danke!

Answer 1

Wahrscheinlich könnten die Pfadnamen alle gleich sein. Sie können die Accept-Header für den MIME-Typ Ihres Kunden gewünschte Antwort, prüfen und dann eine entsprechende Ansicht zurückkehren auf das, was Sie dort finden:

• application/json: JSON Ansicht
• text/xml: XML Ansicht
• text/plain text/html: JSP Ansicht

Browser dieses Feld auf hTML; Ihre JSON-Clients würden einfach dieses Feld als angemessen festlegen.

Answer 2

Es ist höchst unwahrscheinlich, dass jemand eine URL bookmarken würde, die JSON anfordert, daher denke ich, dass es nicht so wichtig ist, die URL sauber zu halten. Es wird wahrscheinlich auch programmatisch erzeugt, nicht von Hand eingegeben. Angesichts dieser Überlegungen würde ich es als Abfrageparameter hinzufügen.

Dies wird nicht Ihre URLs brechen, wenn Sie ID-Parameter haben oder andere Parameter benötigen. Es könnte auch mit POSTs sowie GETs funktionieren.

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

Answer 3

Ich benutze die Konvention von

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

Die Regel ist, dass alle AJAXed Aktionen/Ansichten, die einen Unterstrich haben. Dies sagt mir, dass sie nie Top-Level genannt werden und in der Regel keine Master-Seite zugeordnet sind. In diesem Fall behalte ich die Aktion unter dem gleichen Controller, um jede zugehörige Logik zu teilen.

Regel in der Listenansicht ich ein

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

Answer 4

ich eine leichte Variation/Ausarbeitung auf den Vorschlag von @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 .. Ich glaube, es ist mehr erweiterbar würde empfehlen, hätte . Es sieht beängstigend, aber es ist einfach auf das Format eine ganze Reihe von Dateiformaten aufgefordert, die Dateninhalte durch einen Dekorateur Basis passiert praktisch nur ein paar Zeilen Code zur Verfügung stellen.

Hier ist ein grobes konzeptionelles Beispiel:

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

... Hilfe kann mehr von einer Feature-Liste, technischer Beispiele sein, oder was auch immer Sie wollen. Natürlich können Sie mit nur mit nativen JSON starten und mehr Datenformate zu Ihrem Dekorateur hinzufügen, um Anforderungen wachsen, das ist schön. Für viele meiner Projekte beginnt es als reines json Restzug durch eine AJAX und neigt dazu, in andere Formate zu blühen, die basierend auf der Baustelle Popularität erforderlich sind, so habe ich diese robust genug gefunden für kleinere Projekte in einer Unternehmensumgebung zu verwenden, die oft wachsen groß.