CODEWITHSUNDEEP
apirest
eoinoc
eoinoc

Reputation: 3265

How to define an ID for a (RESTful) API?

For a system which as an internal identifier for a resource (like person_id), does it make sense to give direct API access callable on a different unique value (like licensee_id)?

So would having such an API design be reasonable?

GET /people/{:licensee_id}

And:

PUT /people/{:licensee_id}
{
    "name": "John"
}

Upvotes: 0

Views: 106

Answers (2)

Alberto Zaccagni
Alberto Zaccagni

Reputation: 31560

That means that the resource you're talking about doesn't have a unique identifier, but it has two.

If I were to do it I would expose the same resource from two different URLs, like so:

/licensee/:licensee_id
/people/:person_id

so that if the user of your API in a portion of code is dealing with people (i.e. has easy access to a person_id without any other call) calls the second, otherwise he could call the first.

One of the reasons, beside the fact that it is easier for the consumer of your API, is that it's easier for you to implement, you don't have to understand if what is being passed to you is a licensee_id or a person_id

Upvotes: 2

Erik Nedwidek
Erik Nedwidek

Reputation: 6184

It makes sense to do it this way. You're not really giving up any important information that would make it really any less difficult for someone to do a SQL injection attack (since all foreign keys in other tables that reference the id would have different a name(s) anyway).

If not direct access to the id field, you'd need a different column that is indexed with something like a uuid or md5 created from unique user fields. The only upside I see to doing it this way is that someone would not be able to use the API to "walk" the users or other objects.

Upvotes: 0

Related Questions