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

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

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

/вещи/список для UI, /JSON/вещи для JSON - это потребовало бы JsonController, который бы в конечном итоге служить различные виды объектов, тем самым побеждая шанс разделения объектов, прежде чем мы начнем.
/вещи/список для UI, /вещи/список/JSON для JSON - вероятно мой предпочтительный вариант в данный момент, но требует магического нанизывание (хотя только «JSON»). Кроме того, если вам также нужна сигнатура действия (string id) для принятия некоторых параметров фильтра или таковой, у вас есть выбор добавления дополнительного маршрута или выполнения какого-либо грязного разделения строк.
/счет/MyThings для пользовательского интерфейса, /вещи/список для JSON - немного чище, но не всегда может быть соответствующим контроллером, который вы могли бы служить «вещи» с. Кроме того, вы снова смешиваете объекты.

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

источник

2009-06-06 tags2k

Просьба ознакомиться с моим ответом на [Соглашение о присвоении имен] (http://stackoverflow.com/questions/118474/action-naming-convention/38994001#38994001). Надеюсь, это поможет ... –

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

приложения/JSON: JSON Просмотр
текст/XML: XML Просмотр
текст/равнина, текст/html: JSP Просмотр

Браузеры установить это поле в HTML; ваши клиенты JSON просто установили это поле по мере необходимости.

источник

2009-06-06 12:15:47

Согласен. Это то, для чего предназначено согласование содержимого HTTP. Я бы рекомендовал определить ваши собственные типы mime, чтобы вы могли обновлять форматы данных JSON. Что-то вроде application/vnd.mycorp.myformat-1.0 + json. Таким образом, когда что-то меняется в вашем формате, вы можете изменить его на application/vnd.mycorp.myformat-1.1 + json (для обратного совместимого изменения) или application/vnd.mycorp.myformat-2.0 + json (для отсталой несовместимой изменение). – Nat

Блестяще элегантный, спасибо! Функция jQuery $ .postJSON, которую я использую в своем пользовательском интерфейсе, уже отправляет правильные заголовки, поэтому это прекрасно! – tags2k

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

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

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

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

источник

2009-06-06 12:21:39 tvanfosson

Я использую условность

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

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

Обычно в списке я бы

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

источник

2009-06-06 14:00:17 RedFilter

-1

Я рекомендовал бы небольшое изменение/разработки к предложению по @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 и добавьте больше форматов данных в ваш декоратор по мере роста требований. Для многих моих проектов он начинается как чистый json rest pull от AJAX и имеет тенденцию расцветать в других форматах, которые необходимы на основе популярности сайта, поэтому я нашел это достаточно надежным, чтобы использовать в настройках предприятия для небольших проектов, которые часто растут большой.

источник

2014-02-04 08:11:03 Dave

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

ответ

Смежные вопросы