CODEWITHSUNDEEP
apirestpartitioning
Norbert Hartl
Norbert Hartl

Reputation: 10841

REST API design for nested/hierarchical objects in a scenario with domain model partitioning

I have an HTTP API for let's say applications and those applications have users. The relationship application - user is 1:m. The model is fully partitioned on application. Meaning application is self contained, there is no global pool for users. So in order to find an user I would need to know the application upfront.

Designing the proper REST API for this case I don't find that easy. URIs usual shouldn't be dependent on the way the model is implemented. They should just address the resource. And URIs should be as short as possible, too.

Now I'm thinking about what the URI for a user should look like. Basically I think it would be best to have just

/user/{id}

From an outside perspective this should be good. But I want to keep the partitioning of the data so I neither want having a global pool referencing all application users nor I want to search for a user in all the applications available. That means I need to add some context about the application. Making the URI look like

/application/{id}/user/{id}

would solve the problem. While having my model in mind that makes sense. Application and user are composite, meaning the user has no meaning outside of an application. On the other hand I still think user could be a standalone resource. And my ids are UUIDs so the URL would become very long very quick and it is not that nice looking (if this counts as an argument :) )

The third option would be to put an extra header in the HTTP request. It would be like

X-Foo-Application: {id}
GET /user/{id}

This is how I do it at the moment. Having ids being UUIDs there is no chance (by design of an UUID) that any uri can be exist twice for different resources. But still I'm not sure if that is a proper way to make that compromise between standalone resources and partitioned data.

Or maybe I'm just missing the obvious problem solving approach #4. Any hint is appreciated

Upvotes: 2

Views: 646

Answers (1)

user647772
user647772

Reputation:

Since the IDs of your users are globally unique, I find both

/user/{id}

and

/application/{id}/user/{id}

acceptable. The second path makes the relation of user to application more clear. But I would probably choose the first path based on the globally unique nature of user IDs.

You write:

And my ids are UUIDs so the URL would become very long very quick and it is not that nice looking (if this counts as an argument :) )

Not exactly :)

I don't like your third approach very much. How does the server use the extra X-Foo-Application: {id} header? It is not necessary to identify the user and it is not part of any URI.

Upvotes: 1

Related Questions