: URI design for many-to-many relationship: advice needed I'm stuck designing URIs for a many-to-many relationship between users and other resources. Specifically I'm having difficulty predicting the
I'm stuck designing URIs for a many-to-many relationship between users and other resources. Specifically I'm having difficulty predicting the consequences of different approaches.
Given a resources types user and widget (user represents a registered user), authenticated (logged-in) users have write access to all widgets and guests have read access. The user-widget relation also has data (eg. number of edits) which ideally should also be readable (thus addressable) by guests (and, as Lèse points out below, other users). Examples use integers for unique identifiers for the sake of clarity.
Guests can view widget #12 at
/widgets/12
What are the implications of various possible URIs for authenticated user #34 to read/write widget #12 , and optionally for a guest to read the relational data between the two? (Don't worry about giving a comprehensive answer, any observations for or against specific options would also be very valuable).
/widgets/12
(user is implicit based on authentication, no way for guest to specify user-widget relation)
/users/34/widgets/12
(both sides of the relation explicit, implicit hierarchy between resources)
/users/34/widgets/12 and /widgets/12/users/34
(same, without hierarchy)
/user-widget/34,12
(relation as resource, explicit but possibly more than the user needs to know)
I'm happy to give more detail or add other people's URI suggestions. Just comment if you want me to add anything.
More posts by @Ravi8258870
3 Comments
Sorted by latest first Latest Oldest Best
How does the /widgets/12 form allow guests to read the widgets—or allow users to read the widgets of other users? Or are you planning on implementing multiple forms?
Personally, I would do something like:
/widget/id:12/user:665
/widget/12/665
/widget/12?user=665
Ultimately though, the URL doesn't matter unless this is going to be something that users are gonna want to access directly. If it's just a location to an embeddable script, data feed, or some other type of service, then you can use any URL you want, in which case I'd just go with something like:
/widget?id=12&uid=665
Edit:
I prefer to just serve the widget under /widget since that is what the resource is. I assume that the user-widget relationship is implied by the type of widget it is. So adding users into the path hierarchy is unnecessary.
Now, if you wanted people to be able to browse the widgets of a particular user, then the /users/34/widgets/12 form would be preferable.
The URL for accessing the widget should be the same for everyone. The control of what to show or what capabilities the user has is dependent on the userid, which could be kept, for example, in a session variable.
So when widget/12 loads, your web page should check who the user id is in the session variable, see what their permissions are, and then you would format the page based on those permissions.
If this is about authentication, I wouldn't pass it via the URL at all. What's to stop me from changing the user ID in the URL and getting permissions I'm not supposed to?
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.