1

The more I search Google and SO the more RESTful naming seems like more of a black art than a standard. I would like to lay out a scenario I have and my current line of thinking and ask those of you with REST experience to weigh in.

I have a "Packet" object that you could think of as a physical folder or binder. Inside this packet are one or more forms. My system represents these as a resource called PacketForms. Each form record has a SortIndex column that defines what order the forms are displayed/printed in.

When I display the list of forms in the application, there are up/down arrows that allow the user to change the form's SortIndex. So, now I'm ready to implement this action.

My first thought was to have an operation specifically for promoting/demoting a form in the sort order. If I go with this approach, based on what I've seen here, it seems that I should think about the sort index itself as a resource. So, I could express my intention in a query string like so, right?

PUT /PacketFormSortIndex/5?action=Promote

But I've also thought why not just update the PacketForm itself and let the back-end look for changes in the SortIndex. Rather than a promote/demote approach, if a SortIndex is changed I will swap it with the form that currently has that index. So, if someone updates the PacketForm with SortIndex=3 to have a value of SortIndex=2, the system would update both records to accomplish the swap.

Personally, I like the atomic nature of the first approach. It has a very specific, clear purpose and the code on the back end is cleaner. But if I propagate that logic across my system I worry a bit about "resource sprawl."

So, I guess I have a two later question here. Which, if either, of these approaches feels more "RESTy" to you? If it is the first, is it appropriate to use the querystring in the manner I proposed or is there a more RESTful way to organize that URL?

For something that is being used so widely, I'm really struggling with the wide variety of information I've been finding so your perspective is much appreciated.

4

1 回答 1

1

如果您选择提升/降级或其他方式，您只是在谈论您的 URL 的语法。在幕后，后端必须处理业务并检查哪些其他资源会影响订单更改。

也就是说，创建 PacketFormSortIndex 似乎不是很有用。Waht 将是对 Packet 或 PacketFormSortIndex 应用降级/提升操作之间的区别。对我来说，在语义上似乎是同一件事，因此没有理由单独实体。

最后，我会选择以下任何一种选择：

1）PUT /packet/1 我只会发送正在更新的字段：{"index": 3}，魔术会在幕后发生......但如果我要休息，你应该用更新的资源数组来响应：

[ { "id": 1, "index": 3}, {"id":4, "index":4}]

2）批量方式和确定哪些资源受到影响的逻辑在前端 PUT /packet/_bulk和发送[ { "id": 1, "index": 3}, {"id":4, "index":4}]中。

对我来说，如果后端性能在这里不是问题，我猜不是，最好的解决方案是 1。

于 2013-05-23T22:36:08.573 回答