CODEWITHSUNDEEP
restrestful-urlrestful-architecture
dazedandconfused
dazedandconfused

Reputation: 3186

More RESTful naming

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.

Upvotes: 2

Views: 88

Answers (1)

Daniel Cerecedo
Daniel Cerecedo

Reputation: 6207

Either if you go for the promote/demote or the other way you are talking just about gramatic of your URLs. Behind the scenes the backend will have to do the business and check which other resource affects the order change.

That said, creating a PacketFormSortIndex doesn't seem very useful. Waht would be the difference between applying a demote/promote action on the Packet or the PacketFormSortIndex. For me seems the same thing semantically, so there is no justification for a separate entity.

And finally, I'd go for any of the following alternatives:

1) PUT /packet/1 I'd send only the fields being updated: {"index": 3}, and the magic would happen behind the scenes...but if i was to be resty you should respond with an array of the resources that where updated:

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

2) the bulk way and the logic of determining which resources are affected is in the frontend PUT /packet/_bulk and send [ { "id": 1, "index": 3}, {"id":4, "index":4}].

For me, if backend performance is not an issue here, which i guess is not, the best solution is 1.

Upvotes: 1

Related Questions