Is the use of "me" alias good API design practice?

[kurtkanaskie]

Using a "me" alias in API design hides the value of the identifier.

GET /customers/me/accounts

I can see how this maintains the collection relations and can still allow specific ids to be used in the case where an "admin" user would be able to use a specific customer ID to see their accounts if they called in to a customer representative.

GET /customers/{customer-provided-to-rep-id}/accounts

I realize this adds a bit of complexity to caching and logging.

Is this considered bad API design and an artifact of days gone by?

[ceber]

What's the value? Is it that you hide internal id information from the callers? app users? Some other reason to like it?

[kurtkanaskie]

Not sure, I'm imagining it would make it easy for some Apps to consume the API. For example:

GET /authorize - authenticate user return OAuth token (or POST /token)
GET /customers/me/accounts - return logged in users accounts

Otherwise, with the use of an explicit customerId (UUID) and an opaque OAuth token, how is the customer ID retrieved?

[ceber]

makes sense. But then i wonder.. why bother with "me" at all?

GET /authorize
GET /accounts

If the token dictates what comes back, then admin users can still access anything, and users can still access their own bits.

[kurtkanaskie]

Hmmm, yes I see, that approach would work, is that generally what designers do?

I would still want to be able to get a specific customer's accounts, as in my original use case. So would I provide multiple paths:

GET /accounts - get authorized user accounts
GET /customers/{id}/accounts - specific customer (enforcing auth)

and if the later then am I breaking consistency and confusing the consumer?

Thanks for the discussion!

[ceber]

In my opinion you aren't breaking anything or confusing anyone. But that's just like, my opinion, man.

You always have the option of only publishing the appropriate product to the appropriate consumers.