Can a URL really be considered to be the only key for an HTTP response? - Part 2

I am not sure how this fits into Stack Overflow's moderation guidelines, but I did not at the time of writing Can a URL really be considered to be the only key for an HTTP response? have this particular case in mind, and so decided to continue with this one.

The old story: say one has a site where users need to fetch private assets for authoring, these be images, sounds etc. The problem of URLs for these is now considered resolved in the "first part" of the question. What if, however, users need to fetch the index of their assets (i.e. enumerate them to display as a gallery) and even though the assets are strictly private, site administrators must also be able to access these, for providing support etc. I originally thought of the following URL for such index:

 http://mydomain/user/assets/index

which would indeed work if accessed by a client carrying user authentication and authorization in a cookie. The server will be able to deduce which user asset index to retrieve. The problem arises when a site administrator needs to fetch some users asset index, this is where the URL above is absolutely insufficient for such index identification. The site administrator user agent only sends authentication and authorization for the site administrator himself, it does not in fact identify the user to fetch the asset index for. Is then the best solution to identify the user by the URL, like below?

 http://mydomain/user/<user_id>/assets/ind开发者_运维知识库ex

Thank you for your time.

I would make a completely separate access path for admin activities:

 http://mydomain/this-user/admin/that-user/assets/index

This way, admin is a service, just like any other service (such as your assets service)

I'd probably look to pass the user_id as a parameter rather than in the URL, this would allow you to keep your URI consistent, i.e. :

http://mydomain/user/assets/index?uid=<user_id>

or

http://mydomain/user/assets/index/<user_id>