我理解为什么“REST框架”供应商希望为返回基于Json的表示和基于XML的表示提供支持，但为什么人们想要从同一服务返回？
是否因为您将拥有构建在没有可用的Json解析器的平台上的客户端应用程序？
是否因为您希望更广泛地采用界面，因为您可以吸引更多人？
是否因为您觉得所有RESTful接口都遵循标准惯例？
如果你确实交付了两个：
您是否避免使用XML 中的命名空间，以便它可以与Json格式兼容？或者您是否只有一个名称空间用于所有数据元素？
您是否有某种标准化机制将映射属性和元素转换为某种一致的Json格式，或者您是否只是避免使用XML中的属性？
您是为每个代表创建不同的端点，还是使用内容协商来提供所请求的格式？你有默认格式吗？
如果您对可编辑资源使用缓存并使用不同的网址，那么当一个表示无效时，您如何确保其他表示也失效？
您是否认为支持多种格式的好处值得付出所需？
因此，主要原因似乎是偏好。一些开发人员更喜欢花括号，有些人更喜欢尖括号。
有些人希望从XML迁移到Json，因此需要支持两者才能实现向后兼容。
有些人想使用Json，但担心一些开发人员害怕Json，所以他们支持两者以免冒犯任何人。
很容易在框架XYZ中打开该功能，为什么不呢！
另一个有趣的建议理由是，JSON可以用来提供快速的脏数据摘要，XML可以用作语义丰富的完整表示。
答案 0 :(得分：11)
与迄今为止所说的完全不同的原因 -
REST接口与Resources有关，每个Resource都有一个标识符，即URL。仅仅因为您希望资源使用不同的序列化，无论是XML，JSON，HTML还是其他，我们仍然在描述相同的资源。
因此，我们使用'Accept'标头来确定客户端感兴趣的内容，而不是给出XML与JSON的不同路径。在某些情况下，服务使用'Accept-Language'标头来确定他们应该使用哪种语言作为元数据。
如果我们为记录的不同序列化分配不同的标识符，那么对于语义网，我们必须嵌入额外的信息以链接到描述“相同”对象的所有记录。
您可以在术语Linked Data下找到有关这些工作的更多信息，但这通常是指在序列化中使用RDF。
更新：关于链接到特定格式的讨论，我还建议人们考虑阅读Functional Requirements for Bibliographic Records（又名FRBR），它有关系的概念模型在“书”之间作为抽象的“工作”，与物理的“项目”之间，以及它们之间的级别。 FRBR上的图书馆，信息和语义网络社区有bit of discussion，包括它与数字对象的关系。
基本上，问题在于您可以在多个级别分配标识符（例如，资源，关于资源的元数据的文本，或关于资源的元数据的文本的序列化），以及每个级别有自己的用途。
您可能还会看到OAI-ORE用于报告对象之间关系的规范，包括替代格式或语言。
答案 1 :(得分：7)
Json通常适用于客户端脚本。它是一个超轻量级的响应，JavaScript框架的大部分都带有内置的解析器。 另一方面，许多服务器端应用程序和语言仍然严重依赖于XML。仅举一例：Java。
当然，XML可以用JavaScript和Java（以及大多数其他编程语言）解析至少有一个Json解析器。但目前这似乎是最常见的做法。
谈到“实现与受益”主题，我主要使用Ruby，我可以告诉你Ruby on Rails提供了在不到几秒的时间内从同一个源创建Json或XML响应的能力。在这种情况下，这不是问题，如果我认为它有用，我通常会添加该功能。
使用其他技术，例如PHP，需要更多的努力，实施将有不同的成本。除非这是一个基本功能，否则我可能会坚持一个响应，直到我找不到提供不同版本的需要。
答案 2 :(得分：3)
我自己在History of REST, SOAP, POX and JSON Web Services写了一篇非常详细的文章。基本上详细介绍了不同选项的存在和好处，不幸的是，这里列出所有内容的时间太长了。
基本上，XML更冗长，更严格，更可验证，这使得它成为互操作性的良好候选者，但对于大多数编程语言来说，并不适合程序化。它还支持可以在XSD / DTD文档中找到的模式（即关于数据的元数据）的概念。 WSDL是XSD的扩展，还支持以无限细节（即SOAP Web服务）描述Web服务。
JSON是一种更轻量级，松散类型的文本格式，它实际上是“序列化JSON”，可以为JavaScript提供最佳的编程适应性，因为它可以将JSON字符串原生地eval（）转换为JavaScript对象。缺少命名空间和概念属性/元素使其更适合大多数其他编程语言。不幸的是它只支持基本类型：Number，String，Boolean，Object和Arrays。这并不是互操作性的最佳选择。
我有一些Northwind database benchmarks比较两者，看起来XML平均 2x 等效数据集的JSON大小。虽然如果你的XML文档包含许多不同的命名空间，那么有效负载可能会远远超过它。
答案 3 :(得分：1)
我没有直接了解这一点，因为我只生成REST接口。用于“内部”消费。
在这个不断发展，快节奏和竞争激烈的环境中，我猜测公共API提供商只是“对冲他们的赌注”。
此外，对于hanlding 相对简单的对象模型（大多数可能是这些），处理这两种格式的额外工作量可能很小，因此值得。
答案 4 :(得分：1)
我认为“为什么人们这样做”是非常情境化的。如果为潜在的广泛客户开发应用程序，支持多种内容类型可能会增加适销性 - 既可以了解不同内容类型的含义，又可以了解不同内容类型的人，也可以支持那些支持当今最新流行语的人。 / p>
支持两者的一些原因可能在技术上更合理。应用程序可能需要ajaxy浏览器客户端能够获取页面的信息（JSON会很好），并且可能还需要支持一些可以进行后台处理或批处理的独立API客户端，XML库更方便。
我希望使用内容协商优先于不同的端点，因为使用不同的端点会为REST资源提供同一资源的多个URI，这可能会造成模糊且有时令人困惑的API。
最后，我认为“值得努力”的价值完全取决于您是否知道您可以获得支持多种内容类型的投资回报。如果没有人会使用这两种内容类型中的一种，为什么同时支持这两种内容？当然它们可能很酷，但在很多情况下也可能属于YAGNI。
答案 5 :(得分：0)
我不会读太多内容。我认为一些开发人员更喜欢一个开发人员（特别是取决于你的框架），很容易提供这两个。
我见过的采用这种方法的大多数API都不会打扰XML命名空间
答案 6 :(得分：0)
真的很多开发人员都不懂JSON。我知道这很容易轻量级等，但很多程序员不想花费周期来解决它。他们了解XML，他们对此感到满意，并且在一天结束时，他们真正想要使用它。 JSON也有这种与JavaScript相关联的耻辱，并且自动使它对许多人来说是邪恶的。
支持两者实际上取决于您正在编写API的受众，如果是很多使用旧技术的业务程序员，那么是的，值得支持两者。如果您正在为希望接近边缘的技术行业构建它，那么它可能不值得支持xml。在我工作的地方，我们必须支持两者，我们这样做是值得的。我们了解客户和他们想要的东西，他们付钱给我们为他们提供。
答案 7 :(得分：0)
在许多情况下，服务始于XMP / SOAP，这是几年前唯一的解决方案。然而最近（大约2年左右）JSON变得越来越流行，所以大多数服务决定也支持JSON，因为他们已经有了XML接口，所以他们就保留了它
答案 8 :(得分：0)
就个人而言，我更喜欢只服务器JSON，因为它避免了带宽的角度税。此外，JSON非常精简的事实也很吸引人。
从经验来看，Java和C＃开发人员喜欢在对象中反映XML的能力;这会产生一种静态类型的兴奋效应，因为JSON更容易出现动态行为（即神秘主义或lispism）。
PHP和Ruby程序员往往不关心。
AJAX开发人员更喜欢JSON，因为eval（）是他们的解析器（内置且快速）。
答案 9 :(得分：0)
这取决于您的服务将如何消费。我目前正在处理一项服务，它公开了JSON和XML。
因此，对于我的服务的这种客户端组合，JSON和XML都非常有意义。
我们使用accept标头来确定要返回的响应类型。使用泽西与杰克逊让它变得非常简单。不需要特殊编码来单独处理每一个。 我们不使用名称空间，也不使用属性。