I need an idea for a RESTful implementation of inventory API for an RPG game

Question

I'm working on an kind of an RPG game. And I'm trying to figure out a nice, clean and RESTful way to define inventory API.

inventory consists of several slots like head, chest etc (like in most RPG games).

Now I need to define REST API to move all items from slot X to slot Y.

few ideas I had:

• well, obviously the inventory lives at /inventory
• so 1st idea was to have smth like /inventory/movement and to have a CREATE on that to make it CRUD. so it will be POST /inventory/movement. this will be CRUD and REST, but it feels very bad.
• another one was to have some magic attributes on the inventory and to just do update on it: PUT /inventory?move_from=A&move_to=B. This still doesn't feel too good.

so.. any idea for a clean CRUD REST solution for this?

UPDATE: just had another one: PUT /inventory/:to_slot?from=:from_slot - not sure still. why is the action on just one slot when 2 are involved? hmm... ugh!

Answer 1

Since in REST you should always be acting on a resource, or on a collection of resources, in this case I would consider the 'MOVE' action as the REST resource. This may look incorrect at first, since we consider 'MOVE' to be a verb and not a noun, but this can make sense if the interface covers a high level of abstraction. In a high-level interface which exposes the options available to the user to control the game, you may want to act on the 'MOVE OPTION', which suddenly becomes a noun!

I would therefore use the POST verb to move an item within the inventory, since we would be issuing a request to create a new 'MOVE' action. Consider the following self-explanatory examples:

- POST /move/inventory/a/b
- POST /sell/inventory/a
- POST /use/inventory/b

The 'MOVE' command in raw CRUD operations is normally implemented with a CREATE followed by a DELETE. However, I think you would find it to be too low-level if you were to use raw CRUD operations on game resources like that.

If you were to GET an item from x and PUT it in y, where would you put the validation logic that checks if y is a valid destination? Should it be in the model (behind the interface) or within your game? If it should be in the model, then I think you should consider the high-level approach I described earlier. If, on the other hand you intend to handle this logic within the game (in front of the interface), then you can take the raw CRUD approach, as Jan suggested in another answer.

Note that if your RPG is going to be web-facing, it is imperative that you handle the game logic on the server side. In that case I would seek to map the REST interface one-to-one with the controls and options prompted to the user – and, again, I would suggest the high-level model proposed above.