为什么人们希望将Json和XML作为输出提供给他们的REST接口？
我明白为什么“REST框架”供应商希望提供返回基于Json的表示和基于XML的表示forms的支持， 但为什么人们希望从同一个服务返回 ？
-
是否因为您将有一个客户端应用程序构build在没有可用的Jsonparsing器的平台上？
-
是因为你希望更广泛地采用界面，因为你可以吸引更多的人 ？
-
是否因为你认为所有RESTful接口遵循标准惯例 ？
如果你确实交付两个：
您是否避免使用XML中的名称空间，以便与Json格式兼容？ 或者，你的所有数据元素只有一个名称空间？
你有什么标准化的机制来将属性和元素映射到某种一致的Json格式，或者你是否避免在你的XML中的属性？
您是否为每个表示创build不同的端点 ，还是使用内容协商来提供所需的格式？ 你有一个默认的格式？
如果在可编辑资源上使用caching并使用不同的URL，那么如何确保当一个表示无效时其他表示也失效？
你觉得支持多种格式的好处是值得所需的努力 ？
回应摘要：
所以主要原因似乎是偏好之一。 有些开发人员更喜欢花括号，有些更喜欢尖括号。
有些人希望从XML迁移到Json，因此支持这两者是向后兼容所必需的。
有些人想使用Json，但担心一些开发人员会害怕Json，所以他们都支持这两个，以免得罪任何人。
在框架XYZ中很容易打开这个function，所以为什么不呢？
另一个有趣的推荐原因是，JSON可以用来提供一个快速的脏数据摘要，XML可以用作语义丰富的完整表示。
Json通常适用于客户端脚本。 这是一个超级轻量级的响应，大部分JavaScript框架都带有一个内置的parsing器。 另一方面，许多服务器端应用程序和语言仍然严重依赖于XML。 仅举一个例子：Java。
当然，XML可以使用JavaScript进行分析，Java（以及大部分其他编程语言）至less有一个Jsonparsing器。 但目前这似乎是最常见的做法。
在谈到“实现vs利益”主题时，我主要使用Ruby，我可以告诉你，Ruby on Rails提供了在不到几秒钟内从相同源创buildJson或XML响应的能力。 在这种情况下，这不是一个问题，我通常添加该function，如果我认为它可能是有用的。
使用其他技术，例如PHP，需要付出更多的努力，并且实施会有不同的成本。 除非这是一个基本的function，否则我可能会坚持一个响应，直到我不觉得需要提供不同的版本。
与迄今为止所说的完全不同的原因 –
REST接口关于资源，每个资源都有一个标识符，这些标识符是URL。 仅仅因为你想要一个不同的序列化资源，不pipe是XML，JSON，HTML还是其他的东西，我们仍然在描述相同的资源。
因此，我们使用“Accept”头来确定客户端感兴趣的内容，而不是给XML和JSON一个不同的path。在某些情况下，服务使用“Accept-Language”头来确定什么语言他们应该使用他们的元数据。
如果我们为logging的不同序列化分配不同的标识符，那么对于语义networking，我们必须embedded额外的信息来链接到描述“相同”对象的所有logging。
您可以在“ 关联数据 ”一词下find关于这些工作的更多信息，尽pipe这通常是指在序列化中使用RDF。
更新 ：关于链接到特定格式的讨论，我还build议人们考虑阅读“书目loggingfunction需求” （又名FRBR），它具有“书”作为抽象的“工作” ，物质“物品”，以及两者之间的等级。 FRBR的图书馆，信息和语义networking社区已经进行了一些讨论 ，包括它与数字对象的关系。
基本上，问题是您可以在多个级别分配标识符（例如，资源，关于资源的元数据的文本，或关于资源的元数据的文本的序列化），并且各自具有它们自己的使用。
您可能还会看到OAI-ORE报告对象之间报告关系的规范，包括备用格式或语言。
我自己写了一篇关于REST，SOAP，POX和JSON Web服务历史的详细文章。 基本上详细说明了不同选项的存在和好处，不幸的是，在这里列出所有的内容太长了。
基本上XML是更详细，更严格和可validation的，这使得它成为互操作性的一个很好的候选者，但是对于大部分编程语言而言，这并不是一个适合程序devise的伟大工具。 它也支持可以在XSD / DTD文档中find的模式概念（即关于数据的元数据）。 WSDL是XSD的扩展，也支持描述无限细节的Web服务（即SOAP Web服务）。
JSON是更轻量级，松散types的文本格式，就像有效的“序列化JSON”一样，为JavaScript提供最佳的程序devise适合性，因为JSONstring可以本地eval（）编辑成JavaScript对象。 缺乏命名空间和概念属性/元素使它更适合于大多数其他编程语言。 不幸的是，它只支持基本types：数字，string，布尔值，对象和数组。 这并不是互操作性的最佳select。
我有一些Northwind数据库基准testing比较两者，它看起来像XML平均等效数据集的JSON大小的两倍 。 虽然如果您的XML文档包含许多不同的名称空间，有效载荷可能会大大超出这个范围。
我没有直接了解这一点，因为我只生成REST接口。 为“内部”消费。
我猜测公共API的提供者只是“对冲他们的赌注” ，在这个不断发展，快节奏和竞争激烈的环境中。
此外，为了处理相对简单的对象模型 （其中大部分可能是这些模型 ），处理这两种格式的额外努力可能是最小的，因此是值得的。
我认为“为什么人们这样做”是相当情景化的。 如果为潜在的广泛客户开发应用程序，支持多种内容types可能会增加市场性 – 既可以理解不同types的内容，也可以理解不同的内容types，但支持当今最新stream行语。
支持两者的一些理由可能在技术上更合理。 应用程序可能需要ajaxy浏览器客户端能够获取页面信息（JSON会更好），还可能需要支持一些独立的API客户端，这些客户端可能会进行后台处理或批处理，因此XML库更方便。
我希望使用内容协商优先于不同的端点，因为使用不同的端点会为REST资源提供同一资源的多个URI，这可能会造成模糊，有时令人困惑的API。
最后，我认为“值得付出”的价值完全取决于你是否知道你可以获得投资回报以支持多种内容types。 如果没有人会使用两种内容types之一，为什么同时支持？ 当然，他们可能会很酷，但在很多情况下，也可能属于YAGNI。
我不会读得太多。 我认为有些开发人员比较喜欢一个开发人员（特别是取决于你的框架），提供这两者相当容易。
我所见过的大多数采用这种方法的API都不用担心XML名称空间
真的很多开发人员不了解JSON。 我知道轻量级轻松等等，但是很多程序员不想花费周期来解决问题。 他们知道XML，他们对此感到满意，而在一天结束的时候，这真的是他们想要使用的。 JSON也有与JavaScript相关的这种耻辱，这自然会使很多人感到不幸。
支持这两个方面真的取决于你正在编写API的读者，如果很多使用旧技术的商业程序员，那么是的，值得支持。 如果你想为靠近边缘的科技行业构build它，那么它可能不值得支持XML。 在我工作的地方，我们必须同时支持，这对我们来说是值得的。 我们知道我们的客户和他们想要什么，他们支付我们为他们提供。
在许多情况下，服务是从XMP / SOAP开始的，这是几年前的唯一解决scheme。 然而最近（过去两年左右），JSON变得越来越stream行，所以大多数服务都决定支持JSON，而且由于他们已经有了一个XML接口，
就个人而言，我更喜欢只服务于JSON，因为它避免了对带宽的angular度税。 另外，JSON是一个非常精简的规范，也是很有吸引力的。
从经验来看，Java和C＃开发人员喜欢将XML反映到对象中; 这会产生一种静态types的欣快效果，因为JSON更容易出现dynamic行为（即神秘主义或口齿不清），所以事情不会出错。
PHP和Ruby程序员往往不在意。
AJAX开发人员更喜欢JSON，因为eval（）是他们的parsing器（这是内置的和快速的）。
这取决于你的服务将如何被消耗。 我目前正在开发一个服务，它提供了JSON和XML。
- 由于我的一些客户将是移动应用程序，因此JSON非常适合他们 – 与XML相比，需要较less的处理能力来parsingJSON。
- 我的一些客户将会是使用JavaScript的网页。 由于JSON是Java Script中的头等公民，并且由于我们无法真正确定浏览器运行的系统的计算能力，所以JSON非常合理。
- 其他客户端是服务器端组件，他们可以轻松地处理XML，由于该团队的开发人员熟悉XML，他们更喜欢XML。
因此，为了我的服务，这些客户端的组合，JSON和XML都是非常有意义的。
我们使用accept头来确定返回的响应types。 与jackson一起使用泽西岛使其变得非常简单。 不需要分别处理每一个的特殊编码。 我们不使用名称空间，也不使用属性。
