Соглашения об именовании MVC для действий JSON - PullRequest
Новая
       20

Соглашения об именовании MVC для действий JSON

6 голосов
/ 06 июня 2009

Какое соглашение об именах рекомендуется при написании приложения MVC, имеющего как внешние, так и JSON-пути к требуемым данным?

Например, допустим, у пользователя вашего сайта есть «Вещи». Они должны иметь возможность перейти на страницу, чтобы просмотреть свои вещи, но нам также нужен способ вернуть эти вещи как JSON на других страницах. Мне удалось придумать несколько вариантов, но я недостаточно заинтересован в любом из них, чтобы продолжить. Вот что у меня есть:

  1. / вещи / список для пользовательского интерфейса, / json / вещи для JSON - для этого потребуется JsonController, который в конечном итоге будет обслуживать различные типы объектов, тем самым устраняя любой шанс сущности Разделение, прежде чем мы даже начнем.
  2. / вещи / список для пользовательского интерфейса, / вещи / список / json для JSON - вероятно, мой предпочтительный вариант на данный момент, но требует магического натяжения (хотя это просто "json") , Кроме того, если вам также нужна подпись действия (идентификатор строки) для получения каких-либо параметров фильтра или чего-то подобного, то у вас есть выбор: добавить дополнительный маршрут или выполнить некоторое разбиение грязной строки.
  3. / account / mythings для пользовательского интерфейса, / вещи / список для JSON - немного чище, но не всегда может быть соответствующий контроллер, который вы могли бы обслуживать "вещи" от. Кроме того, вы снова смешиваете сущности.

Все и любые предложения приветствуются, спасибо!

Ответы [ 4 ]

15 голосов
/ 06 июня 2009

Возможно, имена путей могут быть одинаковыми. Вы можете проверить заголовок Accept для mime-типа желаемого ответа вашего клиента, а затем вернуть соответствующее представление на основе того, что вы там найдете:

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

Браузеры устанавливают это поле в HTML; ваши JSON-клиенты просто установят это поле соответствующим образом.

1 голос
/ 06 июня 2009

Я использую соглашение 

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

Правило состоит в том, что все действия / представления AJAX имеют начальное подчеркивание. Это говорит мне о том, что они никогда не называются верхними уровнями и обычно не имеют главной страницы, связанной. В этом случае я сохраняю действие под тем же контроллером, чтобы разделить любую связанную логику.

Как правило, в виде списка у меня будет 

<% RenderAction("_listpage", "things", new {page = ViewData["CURRENT_PAGE"]}); %>
1 голос
/ 06 июня 2009

Маловероятно, что кто-либо будет добавлять в закладки URL-адрес, запрашивающий JSON, поэтому я думаю, что не так важно поддерживать чистоту URL-адреса. Он также может быть сгенерирован программно, а не введен вручную. Учитывая это, я хотел бы добавить его в качестве параметра запроса. 

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

Это не сломает ваши URL, если у вас есть параметры ID или вам нужны другие параметры. Он также может работать как с POST, так и с GET. 

/things/1  -- HTML for "thing 1"
/things/1?format=json -- JSON for "thing 1"
0 голосов
/ 04 февраля 2014

Я бы порекомендовал небольшое изменение / уточнение к предложению @ 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

и т. Д. Я чувствую, что это более расширяемо. Это выглядит страшно, но легко передать содержимое данных через декоратор на основе запрошенного формата, делая целый ряд файловых форматов доступным практически с помощью всего нескольких строк кода.

Вот грубый концептуальный пример: 

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

... справка может представлять собой список функций, технические примеры или что угодно. Конечно, вы можете начать с использования собственного JSON и добавлять больше форматов данных в ваш декоратор по мере роста требований, что приятно. Для многих моих проектов он начинается как AJAX с чистого листа json и имеет тенденцию переходить в другие форматы, которые необходимы в зависимости от популярности сайта, поэтому я нашел это достаточно надежным для использования в корпоративных условиях для небольших проектов, которые часто растут большой.

...