处理预订请求
妥善处理预订请求，避免错误和损失。
概述
设计预订请求工作流程以容忍网络问题非常重要。不要将没有回复解读为预订失败的标志。如果在发送预订请求之后但在收到回复之前出现基础设施问题，旅行者的预订可能仍会在我们的系统中收费并确认。基础设施问题包括：
- 网络连接丢失（没有返回响应）。
- Server-side 返回错误（HTTP 代码 500 或 503）。
- 观察到错误的网络网关（返回 HTTP 代码 502）。
- 观察到网络网关超时（返回 HTTP 代码 504）。
- 响应不遵循 Rapid API 文档（消息中缺少关键元素）。
- 响应不是 JSON 格式（例如，响应消息是 HTML）。
- 其他异常、错误、未知行为或中断。
发出“创建预订”请求后，应使用检索预订请求跟进，其中包括：
- “创建预订”请求中使用的
affiliate_reference_id的原始值和电子邮件地址。 OR - 创建预订响应中返回的
itinerary_id和links.retrieve.href的值。
**注意：**新创建的行程有时在创建时间和可检索时间之间会有短暂的延迟。如果您在尝试检索已成功创建的行程时收到错误，或者您收到同时包含 itinerary_id和 creation_date_time的响应，则请在 following-up 之前重试检索 30 分钟，并与我们的呼叫中心代理联系以获得进一步支持。
推荐的流程
始终发送 affiliate_reference_id
为每个预订生成一个唯一的affiliate_reference_id。如果重新发送相同的请求详细信息（例如由于尝试失败），则应使用相同的 affiliate_reference_id。这可以防止意外的重复预订。发送新的“创建预订”请求时，API 不会响应，直到预订被确认或拒绝。大多数响应会在几秒钟内返回。但是，少数预订可能需要几分钟的时间来处理和生成响应。
监控无法快速解决的预订
Rapid API 连接到外部系统以在 real-time 进行预订。相关系统包括酒店预订或接待系统、信用卡处理器或欺诈检测系统。98% 的预订可以在约 13 秒内完成。但是，如果您在 90 秒后未收到预订响应，请使用与预订一起发送的相同 affiliate_reference_id，通过检索请求检查预订进度。如果预订仍在进行中或预订失败，您将收到 404 错误“使用提供的请求找不到行程”。收到此消息后，您应使用相同的 affiliate_reference_id 再次尝试预订请求。如果预订仍未完成，您将看到一个 400 错误，并显示消息“具有此联盟伙伴参考 ID 的行程已存在”。如果返回此错误，您可以再次检索预订以确认预订详细信息是否可供查看。
处理预订时，检索 API 可能会返回错误或不完整的响应。稍后重试检索预订调用可解决 99.99% 的错误。为了解决性能下降的情况，请重试检索 30 分钟，然后再与我们联系以获得进一步的支持。
预订争议
如果您在预订过程中遇到超时、50x HTTP 代码错误或其他基础设施问题，请提供以下交易日志以供故障排除：
- 预订请求和响应（如有）。
- 上次预订尝试后 30 分钟发送的检索预订请求和响应。
日志应包含请求和响应的 HTTP 标头。响应消息有一个 transaction-id 标头，可以帮助我们识别 Rapid API 交易。