常见错误响应
我们的 API 服务会共享下列常见错误代码、消息和响应格式。
Rapid 错误处理建议
错误处理逻辑
- 平台和合作伙伴应确保已建立错误处理逻辑,以处理购物和预订 API 错误。
- 除非在下面的注释中明确规定,否则每次预订请求都要使用一个独一无二的
affiliate_reference_id。 - 您应该不断审查和更新错误处理逻辑,特别是针对预订请求的错误处理逻辑。
- 所有 Rapid API 响应都有一个对 应的 HTTP 代码,请参阅下面的响应 HTTP 代码列表。
连接超时或通信超时
对于航班 API 预订请求,建议将 API 连接超时设置为 120 秒;对于住宿和其他 API,我们建议设置为 90 秒。但是,您可以决定对购物可用性调用使用较短的连接超时时间。
如果在 120 秒内没有收到响应,Rapid API 将发出 5xx 错误,因为 Rapid API 自身的连接超时设置为 120 秒。
在某些情况下,Rapid API 不支持 HTTP Expect: 100-Continue 过程。使用该进程尝试连接服务器时,您可能会遇到连接问题,尤其是在 cURL、C#/.NET 和其他一些默认遵循该进程的编程语言中。
**注意:**HTTP 504 网关超时并不表示 Rapid 已超时。在这些情况下,要么是基础设施服务发生故障,要么是 Rapid 充当了另一个下游服务的网关,并为该服务设置了超时限制。下游超时将触发 504 错误。如果 504 错误发生在 Booking 调用上,请检查预订是否是使用行程检索(affiliate_reference_id+ 电子邮件)创建的,因为下游问题可能发生在创建预订之前(酒店通信、支付服务器)或之后(Expedia Group 财务管理)。另外,请检查网络 连接是否稳定。Traceroute 命令可能有助于识别连接问题。
处理预订和检索 5xx 错误
预订错误(5xx 状态)或超时并不一定意味着预订本身无效。该错误可能是在预订创建后发生的。我们建议您发送一封包含affiliate_reference_id+ 电子邮件的行程检索请求,以查看预订状态。
在 90 秒内返回的任何错误并不代表预订的最终状态。通常情况下,大多数预订会在 13-30 秒内确认,但有些预订可能需要长达 5 分钟才能确认。
您可以实现逻辑,在 90 秒内检查预订状态 3 次。大多数回复会在前 30 秒内得到确认,您可以无需等待完整的 90 秒即可确认回复。如果仍未收到最终回复,您可以稍后 30 分钟内重试检索,然后再联系 Rapid API 呼叫中心代理寻求进一步支持。
使用 Retrieve API 调用 double-confirm 获取预订结果(HTTP 200 或 HTTP 404 响应)。