如何使用非XML数据表示在RESTful服务中提供链接？

Question

我最近一直在做很多关于如何实现真正RESTful WS的内容.很多人都链接到这里的文章,其中详细说明了如果希望最终得到符合REST概念的服务,实施者应该记住的几个约束.

虽然这个帖子显然很重要,但遗憾的是,我们凡人都很难理解,而且各种各样的人都试图破译它.也许我遇到的最好的解释可以在这里找到,作者给出了一个具体的例子,说明为什么今天许多"RESTful"API真的不是RESTful,并说明了如何纠正这种情况.

他的建议在很大程度上倾向于在暴露资源的表示中使用嵌入链接并且很有意义:我可以清楚地遵循逻辑并且希望自己在我正在设计的一组服务中使用这些技术但是我有一个我不确定应该如何解决的问题:即如果使用的数据表示不是XML而是像JSON那样,应该如何提供这样的链接？

作者所说的一切在XML世界中都很有意义,但我无法清楚地看到如何将其重新应用到其他内容表示中？

非常有兴趣听取其他人的意见,看看人们如何在他们自己的非基于XML的REST API中解决这个问题.

[编辑]:既然我写了这个问题,我发现了以下有用的 链接.回答我的问题还有很长的路要走,但我仍然对其他人的意见感兴趣.

Answer 1

很长一段时间我一直在努力解决这个问题.我得出两个结论: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"模型实际上就是我们在服务器端所做的事情,它的容忍只是因为所有努力使它们看起来像标准数据类型而不是包装器.