4

Good day, I'v implemented a REST service. In the URL of resource end-point I use ID's which are primary keys of tables of the database. For example http://host/myapp/items/item/4. I'v learned using the database ID in the URL is a bad practice and I should use UUID instead. On the other hand I'v learned that using UUIDs in indexes is a performance issue if there's many records in the database because they are not sequential (1,2,3,...). So I'v got an idea to encrypt the database ID. This is how it could work:

1) Client POSTs an item to `http://host/myapp/items`.
2) The back-end creates a new item in the database.
3) Autoincremented ID '4' is generated by the database.
4) The back-end encrypts the ID '4' to 'fa4ce3178a045b2a' using a cipher key and returns encrypted ID of a created resource.

And then:

5) Client sends a request to GET `http://myapp/items/item/fa4ce3178a045b2a`.
6) The back-end decrypts 'fa4ce3178a045b2a' to '4' using an cipher key.
7) The back-end fetches item with primary key '4' and sends it to the client.

What are the cons of such solution? Will the encryption/decryption will be fast enough so that it's not worse then using UUID? And what encryption algorithm should I use so that it is fast and doesn't consume much resources? Could someone more experienced advise or recommend a better solution? Thank you in advance. Vojtech

Vojtech
  • 2,533
  • 9
  • 34
  • 65
  • I find this topic very interesting from API design perspective. Can you please share your findings on performance and what's been decided? – Ivan Gammel Aug 08 '16 at 18:24

2 Answers2

2

yes, ids are sometimes undesired. client can predict and generate the links. can check how big your database is etc. but sometimes it doesn't matter and then ids are perfectly ok.

the fastest ciphers are symmetric ones. for details you have to find/do some benchmarks. example is here: http://stateless.geek.nz/2004/10/13/scp-performance/

but i don't think anyone can tell you if the process of encryption will be faster than using uuid. it depends on your database size, indexes you use, cache, hardware etc. do the performance tests. if speed is critical for you, you can think of storing translation map/table (uuid -> id) in memory

piotrek
  • 13,982
  • 13
  • 79
  • 165
0

I don't think we can predict which is faster: using UUID in your database or encrypting and decrypting the ids. It can depend on the type of the database, the computer the database is on and the actual request as well.

For example when you want to list many resources and you want to add links to the detailed views, you have to encrypt the id of each resource in order to compose the response. Now by a long list this can take a much longer time than a slightly slower select, so I would not use it.

I don't think this is a real bottleneck. I think the HTTP communication is the bottleneck, so in order to make things faster you should consider setting the HTTP cache properly instead. Btw. if you really want to crypt your ids, you should measure the speeds, instead of asking us to guess them.

inf3rno
  • 24,976
  • 11
  • 115
  • 197