构建含knownTravelerNumber的SABRE SpecialServiceRQ遇版本错误等问题咨询

我之前对接SABRE的SpecialServiceRQ时也踩过类似的坑，给你梳理下核心关键点：

• SpecialServiceInfo必须是列表类型吗？
  没错！不管你要添加1个还是多个特殊服务，SpecialServiceInfo都需要以列表形式存在。很多版本错误的根源就是忽略了这个结构——比如直接把SecureFlight或Service节点放在SpecialServiceRQ下，没有包裹在SpecialServiceInfo列表里，这会直接触发schema校验失败，返回版本不匹配的错误。哪怕只有一个服务项，也要保留外层的列表结构。

• Service和SecureFlight需要拆分到独立的SpecialServiceInfo节点吗？
  建议拆分处理。因为SecureFlight属于旅客身份验证类的特殊服务，有自己专属的节点结构（比如需要绑定出生日期、性别等信息），而普通的Service（比如餐食、轮椅服务）的参数要求完全不同。如果把它们放在同一个SpecialServiceInfo节点下，很容易触发格式校验错误，尤其是高版本的API对节点分离的要求更严格。拆分后不仅符合官方的schema规范，也能避免很多莫名其妙的版本错误。

给你一个包含Known Traveler Number的正确请求示例：

<SpecialServiceRQ Version="3.2.0">
  <!-- 单独的SecureFlight服务节点 -->
  <SpecialServiceInfo>
    <SecureFlight SegmentNumber="A">
      <PersonName DateOfBirth="1990-01-01" Gender="M">
        <GivenName>JOHN</GivenName>
        <Surname>DOE</Surname>
      </PersonName>
      <KnownTravelerNumber>123456789</KnownTravelerNumber>
    </SecureFlight>
  </SpecialServiceInfo>
  <!-- 如果有其他服务，单独创建SpecialServiceInfo -->
  <SpecialServiceInfo>
    <Service SSR_Code="KSML" SegmentNumber="A">
      <PersonName>
        <GivenName>JOHN</GivenName>
        <Surname>DOE</Surname>
      </PersonName>
    </Service>
  </SpecialServiceInfo>
</SpecialServiceRQ>

另外补充几个排查版本错误的小技巧：

• 确认请求的Version参数和你使用的API版本完全匹配（比如3.2.0 vs 3.1.0，不同版本的schema差异很大）；
• 检查所有必填属性（比如SegmentNumber、DateOfBirth）是否都正确填写，有时候缺失必填项会被API返回“版本错误”的模糊提示；
• 如果还是不确定，可以把你的请求结构和官方最新的schema做对比，重点看节点层级和列表结构的要求。

内容的提问来源于stack exchange，提问作者user2763281