【问题标题】:What is the best format for documenting XML? [closed]记录 XML 的最佳格式是什么? [关闭]
【发布时间】:2012-01-05 22:38:27
【问题描述】:

我目前正在编写如下 API 的规范:

  • 客户端使用零个或多个 HTTP 参数向特定 URL 发出 HTTPS 帖子
  • 服务器响应一个简短的 XML 文档

正在传输的数据非常轻。大多数响应将小于 1k,最大的只有 10k。

向后兼容性很重要。我希望旧客户端继续在服务器的升级版本上正常工作。

这是我想告诉客户的:-

  • 我希望客户端能够读取 XML,但只访问它需要处理的那些元素。
  • 在服务器升级时,可以随时将其他元素或属性添加到 XML 文档中。客户应该跳过他们不知道的任何事情。

这样即使现在在响应中返回了附加信息,旧客户端也可以继续工作。 (从 XML 中删除元素显然更加困难,并且需要一些弃用过程)。

记录返回的 XML 的最佳格式是什么?

我担心在本文档中使用正式语言(例如 XSD):

  • 添加额外的属性或元素意味着 XML 不符合之前发布的规范
  • 这会诱使编写客户端的人解析 XML 中的所有内容(即使他们不使用它),从而在必要时更难删除元素

或者,我是否在考虑向后兼容性错误?这是一个很好解决的问题吗?客户端是否应该请求特定版本的响应 XML?

【问题讨论】:

    标签: xml api documentation backwards-compatibility


    【解决方案1】:

    IMO,您应该将客户所需的版本连同请求一起发送并返回该格式。因为无论如何您都需要计算以前版本的信息,所以当您知道客户端不会使用它时,无需夸大答案。如果您有一个独立于 xml 的数据结构来支持您的响应代码,您甚至可以将您的 xml 创建器重用于旧式响应。

    当然,这假设响应文档是动态创建的。否则,XQuery 或类似的东西不会完全满足您的要求:仅过滤文档以获取已知元素/值?

    【讨论】:

    • XML 后面是基于业务逻辑和数据库值创建的 POJO。会有一些代码将这些写成 XML。
    • 在这种情况下,您是否建议使用 XSD 并为每个发布的 XSD 添加一个版本号?
    • 当然可以,但我觉得没必要。只要您是这些文档的唯一生产者和消费者,XSD 就只是您的 POJO 的复制品。此外,您将使用比客户端更新的 XSD 版本发送消息。他没有从验证中得到任何东西,旧版本也不会验证。当然,编写模式不会强迫您在生产中使用它。验证消息可能是单元测试的一部分,包括服务器输出和手动客户端输入。
    猜你喜欢
    • 2011-04-25
    • 2020-03-08
    • 2010-09-18
    • 2016-11-23
    • 1970-01-01
    • 2015-08-05
    • 2010-10-23
    • 2012-10-03
    相关资源
    最近更新 更多