在Web服务URL中使用加密数据库ID而不是UUID是个好主意吗？

Question

美好的一天，我实施了一项REST服务。在资源端点的URL中，我使用ID作为数据库表的主键。例如http://host/myapp/items/item/4。我学会了在URL中使用数据库ID是一种不好的做法，我应该使用UUID。另一方面，我了解到如果数据库中有许多记录，因为它们不是顺序的（1,2,3，...），在索引中使用UUID是一个性能问题。所以我有个加密数据库ID的想法。这就是它的工作方式：

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.

然后：

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.

这种解决方案的缺点是什么？加密/解密是否会足够快，以至于它不会比使用UUID更糟糕？我应该使用什么加密算法，以便它快速且不消耗太多资源？有人可以更有经验建议或推荐更好的解决方案吗？先感谢您。 Vojtech

Answer 1

是的，ids有时是不受欢迎的。客户可以预测和生成链接。可以检查您的数据库有多大等等，但有时它并不重要，然后ID就完全可以了。

最快的密码是对称密码。有关详细信息，您必须找到/做一些基准测试。示例在这里：http://stateless.geek.nz/2004/10/13/scp-performance/

但我认为没有人可以告诉你加密过程是否比使用uuid更快。它取决于您的数据库大小，您使用的索引，缓存，硬件等进行性能测试。如果速度对你很重要，你可以考虑将翻译地图/表格（uuid - ＆gt; id）存储在内存中

Answer 2

我认为我们无法预测哪个更快：在数据库中使用UUID或加密和解密ID。它可以取决于数据库的类型，数据库所在的计算机以及实际请求。

例如，当您要列出许多资源并且想要添加指向详细视图的链接时，您必须加密每个资源的ID以构成响应。现在通过一个很长的列表，这可能比稍慢的选择花费更长的时间，所以我不会使用它。

我不认为这是一个真正的瓶颈。我认为HTTP通信是瓶颈，所以为了加快速度，你应该考虑正确设置HTTP缓存。顺便说一句。如果你真的想要隐藏你的id，你应该测量速度，而不是让我们猜测它们。