Question

我们正在为我们的API设计新功能，我们偶然发现了两难。

我们有两种不同类型的资源，具有1-N关系。表示和图层。表示可以包含多个图层。图层只能属于一个表示。我们坚持的是，我们需要维护一个表示层中的图层。

我们提出了两种方法：

第一种方法：链接列表

每个图层都知道它的上一层。在数据库中，这是通过在图层表中包含“父”字段来实现的，该字段包含另一个图层的ID。第一层将“父”设置为NULL。

然后通过以下URI公开API：

创建

GET /Representations/{repID}/layers

获取表示的所有图层。可以通过遍历所有图层并查看父字段来计算订单。

POST /Representations/{repID}/layers

体：标签:(字符串）父：LayerId

这用于通过在请求正文中指定Parent来在特定位置创建和插入图层。如果将Parent设置为NULL，则新创建的Layer将成为订单中的第一个Layer。如果省略“父”字段，则新创建的图层将位于订单的底部。问题在于，在响应中，我们需要通知api消费者其他层由于新插入而改变了顺序。

更新

PUT /Representations/{repID}/layers/{layerId}

体：标签:(字符串）父：LayerId 您可以再次指定一个新的Parent来重新排序图层，然后我们需要再发回一些有关已更改的其他图层的信息。

删除

DELETE /Representations/{repID}/layers/{layerId}

需要发回有关已更改的所有其他图层的一些信息。

第二种方法：图层订购为自己的资源

这个想法是图层本身没有秩序的概念。它们只是一种资源。然后你得到一个layerorder资源，它负责保存关于图层顺序的信息。

因此，您仍将拥有图层的CRUD功能： GET - POST - PUT - DELETE

但是当您想了解他们的订单，或者您想要更改订单时，您将使用以下uri：

/Representation/{repId}/layersorder

此资源仅支持两种方法

GET /Representations/{repID}/layersorder

在此表示中返回一个有序的图层ID列表。

PUT /Representations/{repID}/layersorder

体： [] - 新订单中的图层ID数组。更新图层的顺序。您需要以新顺序传递一个图层数组ID作为请求的主体。（例如[1,3,2,4,6,5]）

根据第一种方法，无论何时添加或删除图层，您都需要通知api使用者另一个资源已更新。在第一种方法中，该方法是受更改影响的图层列表，在此方法中是图层的新顺序（layersorder资源）。

我想听听意见以及类似情况的例子以及你如何解决问题。

感谢。

Answer 1

我经历过你所描述的部分内容。

当执行影响实体（或实体）的PUT / POST时，我喜欢在更改后返回完整对象。希望返回对象不是很大，但如果我使用你的API，第一种方法...我会喜欢做PUT / POST并更新一个层然后用更新的Layer信息获取完整的Representation对象。

这让我很容易确认我的更改，并立即开始使用新结构在我的代码中工作。我不喜欢做PUT / POST和然后必须做额外的GET才能看到变化。

对于第二种方法......我需要做的API工作越多，我就越沮丧。我不确定我是否正确阅读，但是使用第二种方法进行PUT，似乎我必须构造整个表示和图层对象来更新一个数据。那将是令人沮丧的。

我更喜欢第一种方法的语法，但是使用第二种方法的概念。换句话说，这是我希望在PUT / POST / GET之后看到的文档：


{
   "type" : "Representation",
   "id" : 1,
   "layers" : [
      { "id" : 1, "name" : "the first layer", "order" : 1, "parent" : "" },
      { "id" : 2, "name" : "the second layer", "order" : 2, "parent" : 1 },
      { "id" : 3, "name" : "the third layer", "order" : 3, "parent" : 1 }   
   ]
}

它已经为我排序所以我不必做那项工作，但也有用于生成排序的信息以防万一。我已经使用REST API完成了这项工作，它似乎对用户来说非常有用。

REST API如何为需要维护特定订单的资源建模

1 个答案: