We are currently designing a REST API to access classical customer data.
One of the elements in the API are the assets of an user. The assets are added under a given service. The backend API will only add an asset to an user under a given service. So, there’s no User–Asset relation, but a User–[Service]–Asset relationship.
Our URI’s will look like this:
/users/{id}/assets/{id}/services/{id}
Uses of the API will know the asset id and the service id to create a new entry.
What we are struggling with is the creation of this relation.
One straightforward way would be to post the whole relation to /users/{id}/assets/
POST /users/{id}/assets
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}
but then we are not actually creating an asset as the URI might indicate, but an asset-service relation.
As an alternative, we are considering POST’ing to the URI addressing the relation, like this:
POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}
But in this case, the resource path /users/{id}/assets/{id} will not exist before the POST and will be created as a side-effect.
Is POST’ing to a resource path that does not exist yet allowed at all?
Thanks for your thoughts,
Gerard.
It sounds like you’re suggesting that, whenever a user first posts to a non-existent relation, you will create it as part of the post.
If you’re asking whether this kind of create-on-access pattern is a valid, acceptable development pattern, the answer is yes it is – it’s both valid, and a fairly common pattern to see.
1
There are multiple points here:
First:
You should not put the id when create new resource as this id could be already exist, or may be the system using specific technique to generate the id and you are forcing it to use yours, and for the propose of that the id have to be created by the system the location header attribute have to be set in case of creation resource, to get the feed back with the generated id.
Second:
Your JSON is not correct, you have to deal with service as another object inside asset object also as in resource URI service”s” you have to deal with it as array.
POST /users/{id}/assets
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}
has to be:
POST /users/{id}/assets
{services:[{ attribute1:"var", attribute2:"var"}]}
If you are going to use this way
Third:
I do not prefer to use this way for design propose, if this case failed how could you know it is failed while creating asset or service,
Here is a different line of thought:
POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }
This way you are defing the relationships as a three way link between asset, service and user and not implying any hierarchical relationship
You can then retrieve a specific relationship by:
GET /relationships?id="2144321"
or search for a subset of relationships by:
GET /relationships?user="43434"
or
GET /relationships?asset="12433"
The original way is not wrong, but this approach may give you more flexibility over who it gets used.