返回元素的ID有什么好处？它不是已经成为网址的一部分，因此知道吗？我不是在谈论将REST API与HAL或类似的东西一起使用。
PAT1
3
4
PAT2
5
6
PAT2
7
PAT2
我想添加有关API使用的更多信息是有意义的：
有问题的API是封闭网络（不是互联网）中的公共API。我们提供样本客户，但我们的客户为我们的API编写自己的客户。元素的ID不是敏感信息。数据不是关于雇员（如问题中所述），而是关于资产管理。
我问的原因是，客户抱怨如果他们使用某种中间件（无论是什么），他们只接收元素的内容但是无法访问元素的URL（如何？ ）。
如果您编写自己的客户端，是否存在根据URL无法获取ID的情况？我们应该为那些以某种方式无法访问网址的人添加ID吗？
答案 0 :(得分：0)
实际使用该ID的客户是什么？提交产品ID并不是错误的IMO，但是当用户使用电子邮件对API进行身份验证时，用户是否必须知道用户实体在数据库中存储的ID？所以回答实际问题：这取决于。但是，如果客户端正在使用它来构造下一个要调用的URI，我强烈建议返回具有有意义的关系名称的链接，因为这有助于将客户端与API分离，因为客户端不必具有先验知识。 API本身。
根据资源的不同，拥有升序ID可能没有任何好处，因为这可能有利于猜测攻击，如果您删除集合中间的项目，也可能导致奇怪的情况。后续项目的ID是否已更新？物品之间是否有间隙？通常，UUID等是一种更安全的方式来公开这些信息。
另一个需要考虑的方面是，理想REST环境中的客户端不应解释URI本身，而应使用返回URI的关系名来确定是否调用该URI。从URI中提取ID的客户端很可能具有API的先验知识，因此与该API大致耦合，并且如果API将要更改，将会确定地中断。
话虽如此，有一些URI模式的概念可以帮助客户端从URI中提取ID和名称等内容。我个人并不热衷于这样的事情，因为他们在API设计中提出了一种误导性的REST应用方法。
如果您编写自己的客户端，是否存在根据URL无法获取ID的情况？我们应该为那些以某种方式无法访问网址的人添加ID吗？
提取URI的ID需要知道URI结构。如果您以后某个时候想要更改URI结构，无论出于何种原因，围绕该知识构建的所有客户端都将会中断。 URI不应包含实体所在的内容。由于ID似乎是某些客户的内容，因此将其包含在响应正文中。您当然可以自由地将一些信息添加到URI中，但您不应要求客户端解析该URI并提取所需的信息。