Web services 在web服务URL中使用加密的数据库ID而不是UUID好吗？

你好，我提供了休息服务。在资源端点的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更糟糕？我应该使用什么样的加密算法，以使其快速且不消耗太多资源？有经验的人能提供建议或推荐更好的解决方案吗？先谢谢你。是的，ID有时是不需要的。客户端可以预测并生成链接。可以检查您的数据库有多大等，但有时这并不重要，然后ids就完全可以了

最快的密码是对称密码。有关详细信息，您必须找到/执行一些基准测试。例如：

---

但我认为没有人能告诉你加密过程是否会比使用uuid更快。这取决于数据库大小、使用的索引、缓存、硬件等。请执行性能测试。如果速度对您至关重要，您可以考虑在内存中存储翻译映射/表（uuid->id）

我不认为我们可以预测哪个更快：在数据库中使用uuid，还是加密和解密id。它可以取决于数据库的类型、数据库所在的计算机以及实际请求

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

---

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

从API设计的角度来看，我觉得这个主题非常有趣。你能分享一下你对绩效的调查结果和决定吗？