我理解为什么"REST框架"供应商想要提供返回基于Json的表示和基于XML的表示的支持,但为什么人们想要从同一服务返回两者？
是因为您将拥有构建在没有可用Json解析器的平台上的客户端应用程序吗？
是因为您希望更广泛地采用界面,因为您可以吸引更多人？
是因为您认为所有RESTful接口遵循的 标准约定？
如果你确实交付了两个:
您是否避免使用XML中的命名空间以使其与Json格式兼容？或者您是否只有一个名称空间用于所有数据元素？
您是否有某种标准化机制将属性和元素映射到某种一致的Json格式,或者您只是避免XML中的属性？
您是为每个表示创建不同的端点,还是使用内容协商来提供所请求的格式？你有默认格式吗？
如果您在可编辑资源上使用缓存并使用不同的URL,那么如何确保当一个表示失效时其他表示也是无效的？
您觉得支持多种格式的好处是值得的吗？
所以主要原因似乎是偏好.一些开发人员更喜欢花括号,有些人更喜欢尖括号.
有些人希望从XML迁移到Json,因此需要支持两者才能实现向后兼容.
有些人想使用Json,但担心一些开发人员害怕Json,所以他们支持两者以免冒犯任何人.
在框架XYZ中很容易打开功能,为什么不呢!
另一个有趣的建议原因是,JSON可以用来提供快速的脏数据摘要,XML可以用作语义丰富的完整表示.
与迄今为止所说的完全不同的原因 -
REST接口与Resources有关,每个Resource都有一个标识符,即URL.仅仅因为您希望资源使用不同的序列化,无论是XML,JSON,HTML还是其他,我们仍然在描述相同的资源.
因此,我们使用"Accept"标头来确定客户端感兴趣的内容,而不是给出XML与JSON的不同路径.在某些情况下,服务使用"Accept-Language"标头来确定使用何种语言他们应该使用他们的元数据.
如果我们为记录的不同序列化分配不同的标识符,那么对于语义Web,我们必须嵌入额外的信息以链接到描述"相同"对象的所有记录.
您可以在术语关联数据下找到有关这些工作的更多信息,但这通常是指在序列化时使用RDF.
更新:关于链接到特定格式的讨论,我还建议人们考虑阅读书目记录的功能要求(又名FRBR),其中"书"作为抽象"工作"之间的关系的概念模型,与物理'物品',以及它们之间的等级.FRBR上的图书馆,信息和语义网社区已经进行了一些讨论,包括它与数字对象的关系.
基本上,问题是您可以在多个级别分配标识符(例如,资源,关于资源的元数据的文本,或关于资源的元数据的文本的序列化),并且每个都有自己的使用.
您可能还会看到OAI-ORE用于报告对象之间关系的规范,包括备用格式或语言.
Json通常适用于客户端脚本.它是一个超轻量级的响应,JavaScript框架的大部分都带有内置的解析器.另一方面,许多服务器端应用程序和语言仍然严重依赖于XML.仅举一例:Java.
当然,XML可以用JavaScript和Java(以及大多数其他编程语言)解析至少有一个Json解析器.但目前这似乎是最常见的做法.
谈到"实现与受益"主题,我主要使用Ruby,我可以告诉你Ruby on Rails提供了在不到几秒的时间内从同一个源创建Json或XML响应的能力.在这种情况下,这不是问题,如果我认为它有用,我通常会添加该功能.
对于其他技术,例如PHP,它需要更多的努力,并且实现将具有不同的成本.除非这是一个基本功能,否则我可能会坚持一个响应,直到我发现不需要提供不同的版本.
京公网安备 11010802040832号 | 京ICP备19059560号-6 