为什么人们希望将Json和XML作为输出提供给REST接口?

另一方面,许多服务器端应用程序和语言仍然严重依赖XML。仅举一个例子:Java。

谈到“实现与好处”主题,我主要使用Ruby,我可以告诉您RubyonRails能够在不到几秒钟的时间内从同一个源创建Json或XML响应。在这种情况下,这不是一个问题,如果我认为它有用的话,我通常会添加这个特性。

对于其他技术,例如PHP,它将需要更多的努力,实现的成本也会有所不同。除非这是一个基本特性,否则我可能会坚持使用一个响应,直到我发现不需要提供不同的版本。

与目前所说的完全不同的原因--

相同的 资源。

如果我们将不同的标识符分配给不同的记录序列化,那么对于语义web,我们必须嵌入额外的信息来链接到描述“相同”对象的所有记录。

你可以在这个术语下找到更多关于这些努力的信息 Linked Data ,尽管这通常指在序列化时使用RDF。

更新 Functional Requirements for Bibliographic Records bit of discussion 在图书馆中,关于FRBR的信息和语义web社区,包括它与数字对象的关系。

基本上,问题是您可以在多个级别(例如,资源和关于资源的元数据文本,或关于资源的元数据文本的序列化)分配标识符,并且每个级别都有自己的用途。

你可能也会看到 OAI-ORE 用于报告对象之间关系的规范,包括备用格式或语言。

我自己在网上写了一篇相当冗长的文章 History of REST, SOAP, POX and JSON Web Services . 基本上详细介绍了不同选项的存在和好处,不幸的是,这里列出的内容太长了。

JSON是一种更轻量级、松散类型的文本格式,它实际上是“序列化JSON”,为JavaScript提供了最佳的编程适合性,因为它可以将JSON字符串本机eval()转换为JavaScript对象。由于缺少名称空间和概念属性/元素,它也更适合大多数其他编程语言。不幸的是,它只支持基本类型:数字、字符串、布尔值、对象和数组。这并不是互操作性的最佳选择。

我有一些 Northwind database benchmarks 2x

我没有直接了解这一点,因为我只生成REST接口。用于“内部”消费。

我猜公共API的提供者仅仅是 “对冲他们的赌注” 在这个不断发展,快节奏和竞争激烈的环境中,。

支持两者的一些理由可能在技术上更为合理。应用程序可能需要ajaxy浏览器客户端获取页面信息的能力(对于JSON来说是最好的),并且可能还需要支持一些独立的API客户端,这些客户端可以进行后台处理或批处理,对于这些客户端,XML库更为方便。

最后,我认为“值得付出的努力”的价值完全取决于您是否知道您可以从支持多种内容类型的投资中获得回报。如果没有人打算使用这两种内容类型中的一种,为什么同时支持这两种?当然,它们可能很酷,但在很多情况下也可能属于雅格尼。

我所看到的大多数采用这种方法的API都不涉及XML名称空间

实际上,很多开发人员不理解JSON。我知道这很容易,重量轻等等,但是很多程序员不想花时间去弄清楚。他们知道XML,对它很熟悉,最终,这才是他们真正想要使用的。JSON还带有与JavaScript关联的污名,这会自动使它对很多人有害。

支持两者实际上取决于您编写API的对象,如果有很多业务程序员使用较旧的技术,那么是的,两者都值得支持。如果您是为希望接近边缘的技术行业构建它,那么支持xml可能不值得。在我工作的地方,我们必须同时支持这两个方面,我们这样做是值得的。我们知道我们的客户和他们想要什么,他们付钱让我们为他们提供。

在许多情况下,服务是从XMP/SOAP开始的,这是几年前唯一的解决方案。然而,最近(过去两年左右),JSON变得越来越流行,所以大多数服务决定也支持JSON,因为它们已经有了一个XML接口,所以只保留了它

根据经验,Java和C#开发人员喜欢在对象中反映XML的能力;这会产生一种静态类型的欣快效果,因为JSON更倾向于动态行为(即神秘主义或lispism),所以不会出错。

PHP和Ruby程序员往往不在乎。

这取决于您的服务将如何使用。我目前正在使用一个服务,它同时公开JSON和XML。

2. 我的一些客户端将是带有JavaScript的网页。由于JSON是Java脚本中的一级公民,而且我们无法真正确定浏览器运行的系统的计算能力,所以JSON非常有意义。

因此,对于我的服务来说,JSON和XML都是非常有意义的。

我们不使用名称空间,也不使用属性。