6

在我们的 ASP.net Web API 背后，我们有一个代码优先的实体框架模型。考虑以下（简化的）实体：

public class Form
{
    public long Id { get; set; }

    public string Identifier { get; set; }

    public virtual FormGroup Group { get; set; }
}

public class FormGroup
{
    public long Id { get; set; }

    public string Identifier { get; set; }

    public virtual ICollection<Form> Forms { get; set; }
}

如您所见，FormGroups 和 Forms 之间存在一对多的关系。我的问题是，应该如何设计一个允许我们更改表单所属组的 RESTful API？

到目前为止，我提出了两种可能的方法，每种方法各有利弊：

将关系表示为链接结构：

{
    "Id" : 1,
    "Identifier" : "Form1",
    "link" : {
        "rel": "http://myapi/res/formgroup",
        "href": "http://myapi/formgroups/1"
    }
}

优点：

  • 包含指向表单组表示的有意义的链接

缺点：

  • 此类链接没有特定的标准
  • 服务器端逻辑变得更加复杂

使用 PUT 将资源链接在一起

data: {
    "Id" : 1,
    "Identifier" : "Form1"
}

PUT data to http://myapi/formgroups/1/forms

优点：

  • 表示没有无关的属性

缺点：

  • 资源可以由多个 URI 标识，即 /forms/1 和 /formgroups/1/forms/1
  • 发送除了形成密钥所需的任何数据之外的任何数据都是无关的或令人困惑的

我对这两种方法都不是特别满意，因为它们似乎都有更多的缺点而不是优点。

我知道一个“正确”的解决方案是实现 DTO 并将我的实体模型与我的资源表示分离，这将允许我添加一个我可以设置的 FormGroupId。

像所有优秀的程序员一样，我很想知道这是如何在 RESTful API 中工作的。我还想要一个可以普遍应用于模型中任何导航属性的解决方案。

明信片上的答案......这些方法中的任何一种都是有效的，还是有另一种我错过的做事方式？

皮特

4

2 回答 2

2

基于数据模型构建 API 只会限制您的整体设计。我倾向于从我的陈述中恢复过来。

通过完全控制您的陈述，您可以随心所欲地表达关系。例如，您可能决定在您的陈述中包含FormGroup您的Form陈述：

GET /api/forms/1

    {
      "Id" : 1,
      "Name" : "Form 1",
      "FormGroup" : {
        "Id" : 1,
        "Name" : "Form Group 1"
      }
    }

或在表示中包含表格FormGroup：

GET /api/formgroups/1

    {
      "Id" : 1,
      "Name" : "Form Group 1",
      "Forms" : [
        {
          "Id" : 1,
          "Name" : "Form 1"
        },
        {
          "Id" : 2,
          "Name" : "Form 2"
        }
      ]
    }

事实上，你可以两者都做。只需确保每个资源只有一个 URI 标识符。

如果您真的想采用 REST 并在您的 API 响应中包含超媒体链接，我建议您查看超文本应用程序语言(HAL)。HAL 提供了一种用于表达资源之间相关链接的约定。例如：

{
  "_links" : {
    "self" : { "href" : "/api/forms/1" },
    "related" : { "href" : "/api/formgroups/1" }
  }
  "Id" : 1,
  "Name" : "Form 1",
  "FormGroupId" : 1
}

希望您能看到，您如何表示您的资源并不能决定您如何管理它们之间的关系。

你如何做到这一点在很大程度上取决于你的场景中的逻辑，并且通常可以通过决定谁拥有关系来帮助。

举个典型的Blog Post .* Comments例子。评论本身没有什么意义。如果我要设计一个用于管理博客评论的 API，我可能会这样做：

POST   /posts/1/comments  - Add a comment to post 1
DELETE /posts/1/comments/1 - Remove comment 1 from post 1

请注意，评论确实具有身份，但仅在博客文章的上下文中。

在您的情况下（基于我们在推特上的讨论），您说Forms确实在FormGroup. 您还说您可以拥有孤儿表格 - 那些不属于某个组的表格。

考虑到这一点，您可以通过资源管理FormGroup关系。Form最简单的方法是在FormGroupId对表单资源执行 POST 或 PUT 时设置/更新属性。如果（同样这取决于您的方案），您需要能够在FormGroup不更新资源上的任何其他属性的情况下更改Form您可能希望发送 PATCH 或创建“子资源”来管理关系：

POST /api/forms/1/group -- set the form group for forms/1
{
  "formGroupId" : 10
}

DELETE /api/forms/1/group -- unlink forms/1 from its group

不幸的是，没有“正确的方法”来表示您的资源之间的关系。我的建议是选择最自然的方式。

于 2013-02-06T22:15:58.970 回答
1

你说的对。目前，ASP.NET Web API 上的资源世界是混合的，您在某处定义路由，而您必须在其他地方管理资源关系和链接。您可以通过自行定义具有维护和性能影响的每个路由来进行分层路由。

我正在考虑把这些放在一起。看空间:)

现在就回答您的问题而言，我会这样做：

/api/formgroups/1
/api/formgroups/1/forms/123

维护链接和设置路由仍然或多或少是临时的——目前。

于 2013-02-06T22:31:08.720 回答