REST API Design – Using Email as Identifier in RESTful URI

apiapi-designresourcesrestweb services

I'm working with a team building a RESTful web service, and our current implementation utilizes the user's email as a unique identifier for the user resource, yielding URIs like the following:

https://www.domain.com/users/example@gmail.com/resource

Emails are guaranteed to be unique in our system, and we've handled when the user changes his/her email, so it seems OK. But is it correct? The debate is whether we should use an immutable user ID instead, which in our case would look more like:

https://www.domain.com/users/a36571b87be464728c8d/resource

Or perhaps something else altogether. For instance, several Google APIs simply use /users/me/resource and identify the user via auth data.

In a nutshell, is it acceptable to use a unique but mutable identifier in our URIs, or should we use an immutable one?

Thanks!

Best Answer

There are two sub-questions to your question:

  1. Can I use unique but mutable identifiers in my URLs?

    This can work well if either the IDs change only infrequently or if the URLs containing those IDs are not used outside your site. As REST APIs usually are built on the premise that any given URL can be re-used to access the same resource at any later time, that second condition goes a bit against the idea of REST.

    That leaves the probability of changes to the ID and if you are willing/able to redirect requests made using an old ID. With (encoded) email addresses, this can probably be realized, because an old email address will not be re-used by a different user that often.

  2. Can I use email addresses as my unique ID?

    As indicated by the answers of @LucFranken and @9000, using a plain email address in your URL is a bad idea, but you can use an 'encrypted' form of an email address as ID. This 'encryption' can be as simple as base64 encoding.

Related Topic