最近我一直在阅读大量有关如何实现真正 RESTful WS 的资料。很多人都链接到这篇文章 here其中详细说明了实现者如果想要最终得到符合 REST 概念的服务，应该牢记的几个约束。
虽然这篇文章显然很重要，但不幸的是，对于我们这些凡人来说，理解起来相当困难，而且很多人都尝试过 decipher it .也许可以找到我遇到的最好的解释 here ，作者在其中给出了一个具体示例，说明为什么当今存在的许多“RESTful”API 实际上根本不是 RESTful，并展示了如何纠正这种情况。
他的提议在很大程度上依赖于在公开资源的表示中使用嵌入链接，并且很有意义:我可以清楚地遵循逻辑并希望自己在我正在设计的一组服务中使用这些技术我有一个问题我不确定应该如何解决:即如果使用的数据表示不是 XML 而是 JSON 之类的东西，应该如何提供这样的链接？
作者所说的一切在 XML 世界中都非常有意义，但我不清楚如何将其重新应用于其他内容表示？
非常有兴趣听取其他人的意见，看看人们如何在他们自己的、非基于 XML 的 REST API 中解决这个问题。
[编辑]:自从我写了这个问题后，我发现了以下 useful links .这对回答我的问题有很大帮助，但我仍然对其他人的意见感兴趣。
最佳答案
我在同一个问题上纠结了很长时间。我得出了两个结论:a) 用不同的语法重新发明 XML(基本上是那些链接提出的)，或者 b) 决定一些简单的固定约定。
我和b一起去了。对于我现在正在处理的 api，有两种方法可以指定一个链接作为您可以从中获取信息的地方。
首先是在某些情况下该值始终被假定为 URI。应用程序知道它是一个 URI，因为这就是我们的媒体类型所说的它必须是的。
{"form_type": "whatever", "validator": "http://example.com/validatorA"}
第二个是返回的结构化值可以是典型的标准类型(int、string、list、object 等)，也可以是具有“魔法”__ref__ 键的对象。这也是我们如何定义媒体类型的一部分(根据我们应用程序的规则，“__”在属性名称中也是非法的，因此它永远不应该出现)。由应用程序在闲暇时取消引用该值。
{"owner": "john", "attachment": {"__ref__": "http://..."}}
这对我们有用。大多数时候我们关心的值是字符串“john”，而不太关心“john”这个抽象概念是一个Owner资源(其内容不仅仅是唯一标识符“john”)。
为了满足我们的需求，我们用简单性和性能换取了表现力和 REST 正确性。在现实世界中，当结果在 99% 的时间内提供所需的所有信息时，带外信息说“转到/users/$username 以获取更多信息”并不是什么大不了的事。
我们的计划(如果将来有必要)是通过添加 __ref__ 属性来附加链接。
{"owner": "john", "owner.__ref__": "http://ex.com/users/83j9io"}
虽然这不如您提供的链接那么全面，但我认为这是一个合理的平衡。虽然我喜欢每个值都可以链接到其唯一资源和其他元数据(例如您链接到的 json-collections 文档中描述的)的想法，但我认为大多数时候这些信息都是无关紧要的。一个简单的值列表，但您真的需要知道每个值的可寻址 URI、版本、ID 等吗？
它还在代码中引入了烦人的复杂性，必须键入“.value”或“.members”(以及额外访问暗示的所有语义)，而不是能够使用语言原生结构。这种“.value”模型实际上是我们在服务器端所做的，它之所以可以容忍，只是因为所有努力使它们看起来像标准数据类型而不是包装器。
关于xml - 应该如何使用非 XML 数据表示在 RESTful 服务中提供链接？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1768057/