设计一个 REST 资源来管理一个列表

Question

假设我想设计一个用于管理列表的 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 作为特殊标识符是完全合法的（另请参阅我的question）。当然，我可以不使用 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 ...

你怎么看？

Answer 1

您的资源设计完全符合我对 REST 的理解。您可以通过引入一个简单的规则来取消 first 和 last 魔术索引功能来改进您的设计：如果没有提供位置，则更新最后一个项目或插入该项目在最后一个位置。如果你引入这条规则，你就不再需要 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 一书中偷来的，其中作者将两个银行账户之间的转账交易建模为资源。

Answer 2

只是一些想法：

• 像 .../first 或 .../last 这样的 URL 是一种 rpc-ish

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

  GET /list/3/item/2
  

• REST isn't easy 和nested resources 之类的东西需要时间。