JSON 操作的 MVC 命名约定

Posted 2023-02-24

【中文标题】JSON 操作的 MVC 命名约定

【英文标题】：MVC naming conventions for JSON actions

【发布时间】：2010-10-31 20:47:42

【问题描述】：

在编写同时具有所需数据的前端路径和 JSON 路径的 MVC 应用程序时，建议采用哪种命名约定？

例如，假设您网站的用户拥有“事物”。他们应该能够去一个页面查看他们的东西，但我们还需要一种方法将这些东西作为 JSON 拉回到其他页面上。我已经能够想到几个选项，但我对其中任何一个都没有足够的热情继续进行。这是我得到的：

/things/list 用于 UI，/json/things 用于 JSON - 这将需要一个 JsonController 最终服务于不同类型的对象，从而消除任何实体分离的机会在我们开始之前。 /things/list 用于 UI，/things/list/json 用于 JSON - 可能是我目前的首选，但需要魔术字符串（尽管只是“json”）。此外，如果您还需要一个（字符串 id）动作签名来接收一些过滤器参数等，那么您可以选择添加额外的路由或进行一些脏字符串拆分。 /account/mythings 用于 UI，/things/list 用于 JSON - 更简洁一些，但可能并不总是有相关的控制器可以提供“事物” .另外，你又在混合实体了。

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

【问题讨论】：

请看看我在Action Naming Convention 上的回答。希望这会有所帮助...

【参考方案1】：

可以说路径名称可能都相同。您可以检查客户所需响应的 mime 类型的 Accept 标头，然后根据您在此处找到的内容返回适当的视图：

应用程序/json：JSON 视图 文本/xml：XML 视图 文本/纯文本，文本/html：JSP 查看

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

【讨论】：

我同意。这就是 HTTP 内容协商的目的。我建议您定义自己的 mime 类型，以便您可以对 JSON 数据格式进行版本控制。像 application/vnd.mycorp.myformat-1.0+json 这样的东西。这样，当您的格式发生更改时，您可以将其更改为 application/vnd.mycorp.myformat-1.1+json（用于向后兼容的更改）或 application/vnd.mycorp.myformat-2.0+json（用于向后不兼容的更改）改变）。

非常优雅，谢谢！我在 UI 中使用的 $.postJSON jQuery 函数已经发送了正确的标题，所以这是完美的！

【参考方案2】：

任何人都不太可能将请求 JSON 的 URL 加入书签，因此我认为保持 URL 干净并不重要。它也可能以编程方式生成，而不是手动输入。鉴于这些，我会考虑将其添加为查询参数。

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

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

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

【参考方案3】：

我使用的约定

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

规则是所有 AJAX 操作/视图都有一个前导下划线。这告诉我，它们从未被称为***，并且通常没有关联的母版页。在这种情况下，我将操作保留在同一个控制器下，以便共享任何关联的逻辑。

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

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

【参考方案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 开始，然后随着需求的增长向装饰器添加更多数据格式，这很好。对于我的许多项目，它从 AJAX 的纯 json rest pull 开始，并且倾向于根据站点受欢迎程度发展成其他格式，因此我发现它足够强大，可以在企业环境中用于经常增长的小型项目大。