Keeping redundant userid on GET

[fre fri]

We let users log in with Facebook. We're making REST endpoints for getting users FacebookSettings objects. Normally you'd expect something like GET /facebooksettings/{userId}. But we only allow getting of ones own facebooksettings, and only if one is logged in. The userid can be inferred from the token (if it exists) attached to the request, so it seems redundant to send the userid when getting. Should sending the userid be required anyway to conform with normal REST design practices?

[Petros Ziogas]

I don't think you have to keep the facebook id in there.

So if you have 

/user/123/settings 

to retrieve user's 123 settings, using 

/user/123/facebooksettings

to retrieve his facebook settings is good enough.

I would advice against using an id in the url if that id is not controlled by your system. There is no contract that facebook ids will remain the way they are and still make sense for your system after 5 years.

On Mon, May 25, 2015 at 6:52 AM, fre fri <fre.a...@gmail.com> wrote:

We let users log in with Facebook. We're making REST endpoints for getting users FacebookSettings objects. Normally you'd expect something like GET /facebooksettings/{userId}. But we only allow getting of ones own facebooksettings, and only if one is logged in. The userid can be inferred from the token (if it exists) attached to the request, so it seems redundant to send the userid when getting. Should sending the userid be required anyway to conform with normal REST design practices?

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[darrel...@gmail.com]

Hi Fre,

If you wanted to take advantage of shared HTTP caching then putting the user ID in the URL is valuable because it becomes part of the unique identifier of the resource.  But considering you only want authorized users to get the settings then being able to store in a shared cache is likely not a concern.

Arguably, the user ID in the URL and the Authorization token are not redundant.  You may be able to infer one from the other today, but will that always be the case?  Just because a client presents an Authorization token, doesn’t necessarily mean that you will know who the user is.

There are certain other obscure benefits to uniquely identifying user specific content.  Imagine creating a secondary account (maybe for testing purposes).  With unique identifiers you could build a mechanism where you can copy settings from one user to another, assuming you have credentials for both accounts.

TL;DR; There are some benefits to including the user ID but it is not essential.

Darrel

Sent from Surface