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