Konwencje nazewnictwa MVC dla działań JSON

Question

Jaka konwencja nazewnictwa jest zalecana podczas pisania aplikacji MVC, która ma zarówno ścieżki frontowe, jak i JSON do wymaganych danych?

Załóżmy na przykład, że użytkownik Twojej witryny ma "rzeczy". Powinni być w stanie przejść do strony, aby zobaczyć swoje rzeczy, ale potrzebujemy również sposobu, aby wycofać te rzeczy z powrotem jako JSON na innych stronach. Byłem w stanie wymyślić kilka opcji, ale nie jestem na tyle gorliwy, aby którykolwiek z nich mógł kontynuować. Oto co mam:

1. /rzeczy/lista UI, /json/rzeczy dla JSON - Wymagałoby to JsonController które mogłyby skończyć obsługujących różne rodzaje obiektów, a tym samym pokonując każdą okazję oddzielenia istoty, zanim jeszcze zaczniemy.
2. /rzeczy/lista UI, /rzeczy/listy/json dla JSON - prawdopodobnie mój preferowaną opcją w tej chwili, ale wymaga magiczne sznurka (choć tylko "json"). Ponadto, jeśli potrzebujesz również sygnatury akcji (id łańcucha) do przyjmowania niektórych parametrów filtru lub takich, możesz wybrać dodanie dodatkowej trasy lub wykonanie brudnego podziału struny.
3. /konto/mythings dla UI, /rzeczy/lista dla JSON - nieco czystsze, ale może nie zawsze być istotne kontroler, który może służyć do „rzeczy” z. Poza tym znów mieszacie byty.

Wszystkie sugestie mile widziane, dziękuję!

Answer 1

Prawdopodobnie nazwy ścieżek mogą być takie same. Można zbadać Zebrane nagłówek dla typu MIME twojego klienta pożądanej odpowiedzi, a następnie powrócić odpowiedni widok na podstawie tego, co można znaleźć tam:

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

Przeglądarki ustawiony to pole do html; klienci JSON po prostu ustawiliby to pole jako właściwe.

Answer 2

Jest mało prawdopodobne, że ktokolwiek będzie zakładał adres URL, który żąda JSON, więc uważam, że nie jest to tak ważne, aby zachować adres URL jako czysty. Prawdopodobnie zostanie również wygenerowany programowo, a nie ręcznie. Biorąc pod uwagę te, rozważam dodanie go jako parametr zapytania.

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

Nie spowoduje to złamania adresów URL, jeśli masz parametry identyfikatora lub potrzebujesz innych parametrów. Może również działać z POST i GET.

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

Answer 3

używam konwencję

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

Zasadą jest, że wszystkie AJAXed działania/widoki mają wiodącą podkreślenia. Mówi mi to, że nigdy nie są nazywane najwyższymi poziomami i zazwyczaj nie mają powiązania z główną stroną. W takim przypadku zachowam akcję pod tym samym kontrolerem, aby móc współdzielić dowolną powiązaną logikę.

Zazwyczaj w widoku listy chciałbym mieć

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

Answer 4

Polecam niewielką zmianę/opracowanie na sugestię przez @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 .. Czuję, że to jest bardziej rozciągliwy . Wygląda przerażająco, ale łatwo jest przekazać zawartość danych za pośrednictwem dekoratora w oparciu o żądany format, dzięki czemu cały szereg formatów plików jest dostępny z praktycznie tylko kilkoma liniami kodu.

Oto surowy koncepcyjne przykład:

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

... Pomoc może być bardziej listę funkcji, przykłady technicznych lub cokolwiek chcesz. Oczywiście możesz zacząć od posiadania natywnego JSON i dodać więcej formatów danych do swojego dekoratora, gdy rosną wymagania, co jest miłe. W przypadku wielu moich projektów zaczyna się od czystego odpoczynku w wersji json przez AJAX i ma tendencję do rozkwitu w inne formaty, które są potrzebne w oparciu o popularność strony, więc znalazłem to wystarczająco mocne, aby użyć w środowisku firmowym dla mniejszych projektów, które często rosną duży.