2

I am trying to figure out the "right" implementation for an url structure for an application with multitenancy support and shared resources.

Resources: Users, Projects

The URL schema is

host/api/tenant_id/resource[/id][/subresource][/id]

User A (width id = 1) gets a collection of his projects at

GET http://example.com/api/1/projects/

User A creates a new project, readable by

GET http://example.com/api/1/projects/2

Now User A gives another User B (id = 2) access to project 2. User B would like to see a collection of all projects related to his account via:

GET http://example.com/api/2/projects/

Should the shared project (id = 2) be in this collection besides those, User B created by himself? Or is there a better naming structure for shared resources?

Daniel
  • 601
  • 1
  • 4
  • 13
  • Why do you want a tenant ID to identify a project created under a different tenant? –  Mar 02 '15 at 09:21
  • In the application are more resources than just projects. It was my intention to put the tenant as an entry point for the API. So User A with id = 1 can access all his resources at GET http://example.com/api/1/ – Daniel Mar 02 '15 at 09:24
  • To be more precisely, the resource project 2 is now accessible by both User A and User B. Would it be correct, to show project 2 in both collections of projects of User A and User B? – Daniel Mar 02 '15 at 09:39

2 Answers2

4

Focusing on the design of URL structures is actually a no-go for RESTful architectures. Roy Fielding:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server).

See also this answer.

For your specific problem I would return a list of (basically arbitrary) hypertext links to the projects the user has access to. The links would contain attributes making it clear, whether the project is »owned« or »accessible« by the user. To improve readability you could design your resource URLs as

http://example.com/user/{user id}
http://example.com/project/{project id}

The representation of user after a GET http://example.com/user/2 would contain the list of links like 

<a href="http://example.com/project/1" class="owned"/>
<a href="http://example.com/project/2" class="access-permitted"/>

The HATEOAS principle is inherent to REST and makes most »how do I design my URIs« questions obsolete:

The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia.

Community
  • 1
  • 1
xwoker
  • 3,105
  • 1
  • 30
  • 42
  • That makes sense. But what about putting a tenant_id in the url scheme as an entry point? As the application should serve multiple tenants, User A has different resources at example.com/api/projects/ than User B. – Daniel Mar 04 '15 at 07:22
  • Why do you want to return tenant specific projects at example.com/api/projects? why not use the list of projects received from the example.com/api/user/1? What added benefit do you have if you provide the same information using another URI? (It would be different if you want to provide a »project master list« containing all projects with linked resources who owns or is allowed to access the project. – xwoker Mar 06 '15 at 12:28
0

Maybe one advantage can be in using tenant info in the path. In such way we can easily have for example the lists of objects. Querying the uri on get /tenant-id/projects We can have a list of of projects for each entry tenant. How can be get without tenant info into url?

My 2 cents

peterbrown
  • 574
  • 6
  • 13