创建或编辑包含另一个对象的引用/外键的模型时，必须使用该对象的uri。例如，假设我们有两个类：User和Group。每个Group都有User个User个，User只能属于一个组。
然后，如果我们要创建{"name":"John Doe", "group":"/path/to/group/1/"}
，我们可能会发送一个如下所示的对象：
{"name":"John Doe", "group_id":1}
而不是
{{1}}
我认为这与HATEOAS的原则之一有关，但我找不到使用资源uri而不是id的基本原理。使用uri的原因是什么？
（我对哪个更好的意见不感兴趣，但在任何可以帮助我理解这个设计选择的资源中都不感兴趣。）
答案 0 :(得分：1)
我会刺伤
最简单的原因是像你的1这样的代理键意味着系统范围内的东西。它们在系统之外毫无意义。
对此进行扩展，您可以构建应用程序，以便对标识组的URL没有限制，只有从这些URL的响应中收集的资源的一致性。只要两个系统可以协商组是什么，有人就可以在系统中添加FaceBook系统中的组中的用户。像集团这样的概念有标准，并且做这样的事情并非不可能。
这是大多数网络应用的工作方式。 EG：维基百科文章中的引文链接，可以指向任何其他文章（直到维基巨魔删除它而不是适当的引用资源......）
让你的应用程序像这样工作让你更接近RESTful一致性。你是否认为RESTful架构是一个好主意是你要我们不要讨论的，所以我不会。
另一个经常被引用的好处是能够完全重新设置您的设置。你最初可能会忽略这一点......但如果你真的使用1作为id，那可能是int或long，你很快就会用完它们。此类ID也意味着您必须对它们进行适当的排序。在某些时候，你可能希望你使用guid作为你的身份。任何坚持旧ID计划的人都将被视为遗产。网址为您提供了一点抽象。这个网址仍然是传统的东西，但识别遗留网址比识别遗留网址更容易（授予不多... ＃39;很容易知道你是否获得了长或guid，但更容易看到一个url为/ old / path / group / 1 vs / new / path / group /）。通常使用URL可以为您提供更多的向前兼容性和增长空间。
我还发现提供URL作为标识符使客户端很容易检索有关该事物的信息。自我链接非常方便。假设我对一个群体有一些参考：1 ....这有什么用处？有多少UI会显示一个控件，说明＆＃34;添加组1＆＃34;。你想要展示更多。如果您将URL作为选择标识符传递，则客户端始终可以检索有关该选择实际是什么的更多信息。在某些应用程序中，您可以传递整个对象（包括id）来处理这个问题，但是保存URL以便以后检索（想想书签）会很好。更重要的是，能够定期刷新该对象以获得最新状态总是很好。一个自我链接可以非常好地做到这一点，并且我认为它总是包含......并且如果一个总是包含的自我链接识别资源...为什么你还需要提供你的代理键作为辅助标识符？
一方注意。我试图避免需要url作为参数的服务。我更喜欢创建用户，而不是让服务提供可能的组成员资格作为链接，然后让客户选择请求从非成员资格到成员资格的状态转换。如果你需要＆＃34;用组创建用户＆＃34;在新用户实际提交/承诺服务之前，我会选择中间状态。我发现客户端提供的输入越少，应用程序就越容易使用。