rest - 设计一个 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 只是一个表示索引 0 的魔法字符串，last 由于上述规则已过时。

正如@miku 所说，您的元素可能是它们自己的资源。如果您计划更通用的资源列表设计，您需要在一个列表中管理不同的资源类型(例如，列表可以管理任务、 session 、约会)，则列表项可以再次引用(使用资源 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)状态，“操作”资源的句柄(通过位置 header )，您可以在其中检查操作状态，以防您要移动，异步交换，返回为您提供所有列表位置操作的某种日志的资源。

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