MVC命名约定的JSON操作

Question

当编写一个既有前端路径又有JSON路径的MVC应用程序时，推荐使用什么命名约定？

例如，假设您网站的用户有“物品”。他们应该能够进入页面查看他们的物品，但我们还需要一种方法在其他页面上以JSON格式检索这些物品。我已经想到了几个选项，但我对它们中的任何一个都不太满意。以下是我的想法：

1.对于UI，使用/things/list，对于JSON，使用/json/things - 这将需要一个JsonController，最终会提供不同类型的对象，从而在开始之前就破坏了任何实体分离的机会。

2.对于UI，使用/things/list，对于JSON，使用/things/list/json - 目前可能是我最喜欢的选项，但需要魔术字符串（尽管只是“json”）。此外，如果您还需要一个（字符串ID）操作签名来接收某些筛选参数之类的内容，则可以选择添加额外的路由或进行一些肮脏的字符串拆分。

3.对于UI，使用/account/mythings，对于JSON，使用/things/list - 更加简洁，但您可能没有相关的控制器可以服务于“things”。此外，您再次混合了实体。

欢迎提出任何建议，谢谢！

- tags2k

---

请查看我在 Action Naming Convention 上的回答。希望这能有所帮助... - Murat Yıldız

Answer 1

可以说路径名称都可以相同。您可以查看 Accept 头以获取客户端所需响应的 mime 类型，然后根据您在那里找到的内容返回适当的视图:

• application/json: JSON 视图
• text/xml: XML 视图
• text/plain、text/html: JSP 视图

浏览器将此字段设置为 HTML; 您的 JSON 客户端将根据需要设置此字段。

- Peter Bratton

---

我同意。这就是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

非常优雅，谢谢！我在我的用户界面中使用的$.postJSON jQuery函数已经发送了正确的标头，所以这很完美！ - tags2k

Answer 2

很少有人会收藏请求JSON的URL，因此我认为保持URL干净并不那么重要。它也很可能是通过程序生成的，而不是手动输入的。考虑到这些因素，我建议将其添加为查询参数。

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

如果您有ID参数或需要其他参数，这不会破坏您的URL。它也可以与POST和GET一起使用。

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

- tvanfosson

Answer 3

我使用的惯例是

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

规则是所有 AJAX 动作/视图都有一个前导下划线。这告诉我它们从不被调用顶层，通常没有关联的主页面。在这种情况下，我将操作保留在同一个控制器下，以便共享任何相关逻辑。

通常在列表视图中，我会有一个

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

- D'Arcy Rittich

Answer 4

我建议对@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拉取，通过AJAX进行扩展，以满足基于站点流行度的其他所需格式，因此我发现它足够强大，可用于较小的企业项目。

- Dave