我理解为什么“REST 框架”供应商希望支持返回基于 Json 的表示和基于 XML 的表示，但为什么人们希望从同一个服务返回两者？

• 是不是因为您的客户端应用程序构建在一个没有可用的 Json 解析器的平台上？

• 是因为您希望界面得到更广泛的采用，因为您可以吸引更多人？

• 是不是因为您觉得它是所有 RESTful 接口(interface)都遵循的标准约定？

如果您同时交付:

您是否避免在 XML 中使用命名空间以使其与 Json 格式兼容？还是您的所有数据元素都只有一个命名空间？

您是否有某种标准化机制来将属性和元素映射 为某种一致的 Json 格式，或者您是否只是避免在 XML 中使用属性？

您是为每个表示创建不同的端点，还是使用内容协商来提供请求的格式？你有默认格式吗？

如果您在可编辑资源上使用缓存并使用不同的 URL，您如何确保当一个表示无效时其他表示也无效？

您觉得支持多种格式的好处值得付出努力吗？

回复摘要:

所以主要原因似乎是偏好之一。一些开发人员更喜欢花括号，一些开发人员更喜欢尖括号。

有些人希望从 XML 迁移到 Json，因此需要同时支持两者以实现向后兼容性。

有些人想使用Json，但担心有些开发者害怕Json，所以他们都支持，以免得罪任何人。

在框架 XYZ 中开启该功能很容易，何乐而不为!

另一个有趣的建议原因是，JSON 可用于提供快速的脏数据摘要，而 XML 可用作语义丰富的完整表示。

最佳答案

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

REST 接口(interface)是关于资源的，每个资源都有一个标识符，即 URL。仅仅因为您希望资源具有不同的序列化，无论是 XML、JSON、HTML 还是其他内容，我们仍然在描述 same 资源。

因此，我们使用“Accept” header 来确定客户端感兴趣的内容，而不是为 XML 和 JSON 提供不同的路径。在某些情况下，服务使用“Accept-Language” header 来确定他们应该为元数据使用什么语言。

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

您可以在 Linked Data 下找到有关这些努力的更多信息。 ，尽管这通常是指在序列化时使用 RDF。

更新:关于链接到特定格式的讨论，我还建议人们考虑阅读 Functional Requirements for Bibliographic Records (又名 FRBR)，它有一个概念模型，用于描述作为抽象“作品”的“书”与物理“项目”之间的关系，以及两者之间的层次。有一个bit of discussion FRBR 上的图书馆、信息和语义网络社区，包括它与数字对象的关系。

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

您可能还会看到 OAI-ORE用于报告对象之间关系的规范，包括替代格式或语言。

关于xml - 为什么人们希望将 Json 和 XML 作为输出传递到他们的 REST 接口(interface)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1649793/