4

美好的一天，我已经实现了一个 REST 服务。在资源端点的 URL 中，我使用 ID，它们是数据库表的主键。例如http://host/myapp/items/item/4. 我了解到在 URL 中使用数据库 ID 是一种不好的做法，我应该改用 UUID。另一方面，我了解到，如果数据库中有很多记录，那么在索引中使用 UUID 是一个性能问题，因为它们不是连续的（1、2、3、...）。所以我有一个想法来加密数据库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 更糟？我应该使用什么加密算法才能快速且不消耗太多资源？更有经验的人可以建议或推荐更好的解决方案吗？先感谢您。沃杰科技

4

2 回答 2

2

是的，身份证有时是不受欢迎的。客户端可以预测和生成链接。可以检查您的数据库有多大等，但有时这并不重要，然后 id 就可以了。

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

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

于 2014-12-05T11:56:28.463 回答
0

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

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

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

于 2014-12-06T19:44:30.780 回答