Question

Suppose I have to implement game character resource. Character could have only one weapon.
Weapon types are different (sword, knife, gun etc.) and have different set of properties.
Character and Weapon are separate resources for sake of usability.
In OOP model it will looks as follows

What will be the best way to design URIs and resources for such structure?

edit:
In general. Is it ok to have in Character resource link to weapon resource that return Knife, Sword or Gun or it have to be the link to certain resource such as http:\game.com\character\sword?

Answer 1

In general, the REST model can be mapped directly as “Object” <-> “Representation” and “OID/References” <-> “URI”. So first, what you have to do is to assign each of the elements present in the game a different URI.

Option 1

Say you use JSON to describe the character, so you would have something like this:

URL: /character/Warrior

Content:

{ "name" : "Warrior", "weapon" : "/weapons/id_of_weapon" }

Note how the “weapon” includes a link (or an array of those) to the different weapons that the character has. Each of those, following the REST principle, is identified by an URI.

You have now two options to suport the type/subtype variation:

Use different MIME types

When you obtain the resource /weapons/id_of_weapon, you’ll get, say, a response from the server in which the headers look like this:

HTTP/1.1 200 OK
...
Content-Type: my-game/Knife
... (more headers)

Knife data Content

This identifies the actual type of the element returned, and can be used to map it to the different subtype. You can use different schemes, such as Weapon/Knife, or MyGameObject/Weapon_Knife.

Use content-based object mapping

Also, you can explicitly set the type of the returned instance. In this case, you could get a response like this:

HTTP/1.1 200 OK
...
Content-Type: application/json
... (more headers)

{ "type" : ["Weapon", "Knife"] , ... (rest of fields) }

Note how the type JSON parameter is used as a standard in your game to specify the different types supported by that returned data.

Option 2

You may also consider, after your edit, that you can mimic the resource containment architectur in URIs. However, you propose http://whatever/character/sword. This is not appropriate, because you’re naming classes, and not resources. A more appropriate URL scheme would be something like:

http://whatever/character/idc/weapon/idw

where idc and idw are the identifiers of the character and the weapon respectively. Note that you don’t fix the exact type of the weapon in the resource URI (that is, you have to say weapon, not knife), but it may happen that actually the weapon with the id idw is actually of type Knife (using either of the options given above).

If you map containment to URIs, you can also have a more compact format for the character as follows:

{ "id": "idc",
  "name" : "Warrior", 
  "weapon" : { "id": "idw", "type": "Knife", (rest of knife properties) }
}

Note how: each element has its own id. Containment is observed via JSON recursive object inclusion, you also specify the type of the weapon, and, still you can map the URL scheme just described to access the inner elements of the character.