Is it a bad idea to use a database table's ID as an external API identifier?

Question

We're designing a HTTP service with an external API, which will need to store some items, that external API consumers might need to retrieve later on. Everything is stored in a table foos , and the current plan is to just use the table's primary ID key as the external unique identifier. My gut tells me this is bad design, but I've not been able to argue my case effectively, partially because I can't articulate the reasons.

Here are the only downsides I can think of so far:

• What if we want to change the schema? We'll have to repopulate everything making sure their IDs stay intact, or implement another unique identifier column during the move
• Minor(?) security risk (I know, security through obscurity is not secure etc etc)

Are there other major downsides, or am I just being paranoid? Would also appreciate some links to published articles which talk about this!

Answer 1

Im going to go ahead and say that if your database is locked down than this does not matter unless:

• Sharing API keys implies a loss in CIA of user information.
• You make it easy for users to make calls to your API without second level authentication.

What I'm sure you already realize is that taking measures against SQL injection will prevent anyone taking advantage of this information, however knowing an index range could mean that someone will know that 1 less or 1 more in an index range is a tangible key to be used to access your API.

---

For example:

If you can access your API through a URL without being logged in, then using an index range is a bad.
http://mysite.com?APIkey=145
If I know my key is 145 , then 144 and 146 probably would also work to make a call.

Using a GUID scheme is way to deal with this but with this you are making other sacrifices :
ID (index): 145
ID (GUID): C87FC84A-EE47-47EE-842C-29E969AC5131

---

Or finally, you can add another column to save a random hash as a unique API key like you said:
ID (Hash): da39a3ee5e6b4b0d3255bfef95601890afd80709

Answer 2

It is perfectly safe. The ids will get backed up and restored with the rest of the data, so there is no problem there. Nor are there any security issues that I can think of. Whether it is bad design is a matter of taste.

IIRC the eBay and PayPal APIs work this way, but I cannot quote a reference on that.

Answer 3

I agree with you because of your first point:

If you end up changing schema for whatever reason your service should abstract the physical changes. Maintaining the old keys makes that very hard....