4

假设我想设计一个用于管理列表的 REST 存储。列表条目看起来像这样：

<listentry>
    <position>0</position>                <!-- position in the list -->
    <data>interesting information</data>  <!-- entry data -->
</listentry>

我会这样设计资源：

GET    /list/           // returns all list entries
GET    /list/{position} // returns the list entry at {position}
DELETE /list/{position} // delete list entry at {position}

PUT    /list/first      // update first list entry
PUT    /list/last       // update last list entry
PUT    /list/{position} // update entry at {position}

POST   /list/last       // inserts a new list entry at last position
POST   /list/first      // inserts a new list entry at first position

POST   /list/{position} // inserts a new list entry at {position} and moves all 
                        // entries down  the list starting from the entry that
                        // was at {position} before the insertion.

这是合法的 REST 资源吗？如果没有，有没有办法设计一个休息资源，以便它可以管理一个列表？

编辑

感谢您的投入，它确实有帮助。我同意 nategood 和 darrel 的观点，即使用 first 和 last 作为特殊标识符是完全合法的（另请参阅我的问题）。当然，我可以不使用 Saintedlama 建议的那些神奇标识符，但这会剥夺我在我现在想向您展示的帖子请求中使用它们的可能性。

在再次考虑设计时，我想在我的资源设计建议中添加两个额外的功能。

POST   /list/{position1}/swap/{position2}   // swap the position of two elements
POST   /list/{position1}/move/{position2}   // move the element at {position1} to
                                            // {position2} and move all entries 
                                            // down the list starting from the 
                                            // entry that was at {position2}

//possible uses
POST   /list/first/swap/last                // swap first with last element
POST   /list/42/swap/2                      // swap element 42 with element 2
POST   /list/first/move/42                  // move first element to position 42
// you get the idea ...

你怎么看？

4

2 回答 2

2

您的资源设计完全符合我对 REST 的理解。您可以通过引入一个简单的规则来取消第一个和最后一个魔术索引功能来改进您的设计：如果没有提供位置，则更新最后一项或将该项插入到最后一个位置。如果你引入这条规则，你就不再需要 first and last 了。First 只是一个表示索引 0 的魔术字符串，last 由于上述规则已过时。

正如@miku 所说，您的物品可能是它们自己的资源。如果您计划一个更通用的资源列表设计，您需要在一个列表中管理不同的资源类型（例如，列表可以管理任务、会议、约会），则列表项可以再次引用（使用资源 url）到项目资源。使用这种引用方法，您可以将列表保存功能与列表项表示完全分离。

编辑：

这个问题正在得到一个移动的目标:)

您可以将所有与位置相关的操作建模为资源，并将操作建模为您创建的子资源，如下所示：

POST   /list/positions/swap/0/2   // swap the position of two elements
POST   /list/positions/move/1/0   // move the element at 1 to 0

如果操作成功与否，此位置资源可以返回（HTTP）状态，“操作”资源的句柄（通过位置标头），您可以在其中检查操作的状态，以防您想要移动、交换异步、返回为您提供所有列表位置操作的某种日志的资源。

将头寸建模为资源的想法是从RESTful Web Services一书中窃取的，其中作者将两个银行账户之间的转账交易建模为资源。

于 2012-04-08T07:31:30.827 回答
1

只是一些想法：

  • 像 .../first 或 .../last 这样的 URL 有点 rpc-ish

  • 一个列表项似乎是它自己的资源，所以它最终应该被当作一个资源来处理，例如：

    GET /list/3/item/2

  • REST 并不容易，需要花费时间来了解嵌套资源等。

于 2012-04-07T23:54:46.997 回答