Lunar Flow | Retrying Failed Requests to Booking.com API

By using this retry policy, you can retry failed requests and attempt to get a successful response for them. The retry policy can help you reduce API error rate by making multiple attempts when needed. API calls to the Booking.com API can often fail for internal reasons - implementing retries can help avoid these failures propagating to your services.

1. [RESPONSE] Retry processor - this processor checks if the response returned from the API is successful or not based on its status code (the range of codes that are considered successful can vary). If a response is successful, it’ll be passed on to the consumer. If it isn’t it’ll be retried with the API. You can define the maximum number of retries as well as the cool off period between retries - see below for full details.

Configuring API Call Retry for Booking.com API:

You can see a sample configuration below for setting up a queue policy for Booking.com API. For full details, please see the documentation for the queue policy.

endpoints:

  - url: api.com/resource/{id}

    method: GET

    remedies:

- name: Retry

      enabled: true

      config:

        retry:

          attempts: <attempts>

          initial_cooldown_seconds: <initial_cooldown_seconds>

          cooldown_multiplier: <cooldown_multiplier>

          conditions:

            status_code:

              - from: <min_status_code>

                to: <max_status_code>

The following configurations are available for this policy:

• allowed_request_count: Specifies the maximum number of requests allowed within each defined time window. Set this as a positive integer to control the rate of API calls.
• window_size_in_seconds: Defines the duration of the time window in seconds during which the allowed requests can be made. This helps regulate the flow of requests.
• ttl_seconds: Indicates the time-to-live for a request in the queue, measured in seconds. If a request stays in the queue longer than this time, it is discarded.
• queue_size: Sets the maximum number of requests that can be held in the queue at any given time. This limits the total number of pending API calls.
• response_status_code: Determines the HTTP status code returned to the client when a request is dropped due to exceeding the TTL. Commonly set to 429 for "Too Many Requests."
• prioritization.group_by.header_name: Specifies the HTTP header name used to identify which priority group a request belongs to. This allows requests to be categorized based on the value of a specific header.
• prioritization.groups.group_name: Defines the name of each group used for prioritization. This could be something like "production" or "staging."
• prioritization.groups.*.priority: Assigns a priority level to each group. Lower numbers indicate higher priority, ensuring more critical requests are processed first.

Why to use API Call Retry for Booking.com API:

Retry is a common strategy for increasing application reliability and protecting your application from unexpected API outages or errors or temporary denial of service.

Retries to reduce Booking.com API errors:

Implementing a retry mechanism can significantly decrease the impact of transient Booking.com API errors on your application. When an API request fails due to temporary issues like network instability, server overload, or brief outages, automatically retrying the request can often result in a successful response. An effective retry strategy typically involves using an exponential backoff algorithm, which increases the delay between retry attempts to avoid overwhelming the API server. It's important to set a maximum number of retry attempts and to only retry for errors that are likely to be resolved by subsequent attempts. By intelligently retrying failed requests, you can improve the reliability of your Booking.com API interactions, enhance user experience, and reduce the need for manual intervention or error reporting.

Retries to improve Booking.com API reliability:

Implementing a robust retry mechanism can significantly enhance the reliability of your interactions with Booking.com API. By automatically retrying failed requests, your application can overcome transient issues such as network fluctuations, temporary server overloads, or brief service interruptions. An effective retry strategy typically employs an exponential backoff algorithm, gradually increasing the delay between attempts to avoid overwhelming the API server. It's crucial to set appropriate retry limits and only retry for errors that are likely to be resolved on subsequent attempts. This approach not only improves the overall success rate of API calls but also enhances the resilience of your application. By gracefully handling temporary failures, retries help maintain consistent functionality and provide a smoother user experience, even in the face of intermittent Booking.com API issues.

Retries to deal with Booking.com API rate limits:

Implementing a retry strategy can be an effective way to manage Booking.com API rate limits and ensure your application continues to function smoothly. When your requests exceed the API's rate limit, you'll typically receive a specific error response. Instead of failing outright, this retry policy can let your application retry the request - and by using the cooldown parameter you can wait between attempts, which will hopefully let the rate limit reset. This approach not only helps your application respect Booking.com API's usage policies but also maximizes your ability to successfully complete API operations within the given constraints, improving overall reliability and user experience.

Retries to improve resilience with Booking.com API:

Implementing a well-designed retry strategy can significantly enhance your application's resilience when interacting with Booking.com API. By automatically retrying failed requests, your system can gracefully handle a variety of temporary issues, such as network instability, server-side glitches, or brief outages. By intelligently retrying operations, you can create a more fault-tolerant system that can withstand and recover from transient failures, ensuring a more consistent and reliable user experience. Additionally, retries can help manage rate limits and optimize resource utilization, further contributing to a robust and resilient integration with Booking.com API.

Best Practices for Retries with Booking.com API:

Retry only appropriate errors:

• Focus on transient errors that are likely to be resolved by retrying
• Examples include network timeouts, 500-series server errors, and certain 429 (rate limit) errors
• Avoid retrying client errors like 400 (Bad Request), 401 (Unauthorized), or 404 (Not Found) - a bad request is unlikely to suddenly work with a retry
• Consult Booking.com API's documentation for specific error codes that are suitable for retries

Implement exponential backoff:

• Start with a short delay (e.g., 1 second) and increase it exponentially with each retry
• This approach helps prevent overwhelming the API server and allows time for issues to resolve - especially transient network issues and rate limiting problems

Set a reasonable maximum number of retry attempts:

• Typically, 3-5 attempts are sufficient for most scenarios
• Balance between persistence and avoiding excessive resource usage
• Consider the nature of your application and the criticality of the API call when determining this limit
• Remember that if an API is experiencing an outage / is overloaded, multiple attempts can further exacerbate the problem and make recovery more difficult

Use request timeouts:

• Set appropriate timeouts for each API request to prevent indefinite waiting
• Adjust timeout values based on the expected response time of different API endpoints

Implement circuit breakers:

• Temporarily disable retries if a high number of requests are failing consistently
• This prevents unnecessary load on both your system and the API server during prolonged outages

Log and monitor retry attempts:

• Keep track of retry frequency and success rates
• Use this data to optimize your retry strategy and identify recurring issues
• Combine the retry policy with the Lunar Log Collector to effectively understand your retry performance

Handle rate limits intelligently:

• If you receive a rate limit error, respect the "Retry-After" header if provided by Booking.com API
• Implement a cooldown strategy specific to rate limit errors
• With Lunar, you can set multiple retry policies on different ranges - so you may want to have one policy for 5xx issues with a shorter retry period, and a different retry policy for 429 (Too Many Requests) issues with a longer cooldown period.

Use idempotency keys for non-idempotent operations:

• When retrying operations that aren't naturally idempotent (e.g., POST requests), use idempotency keys if supported by Booking.com API
• This prevents unintended duplication of actions in case a retry succeeds after an initial success was not properly acknowledged

Implement request queuing:

• For non-time-sensitive operations, consider queuing failed requests for later retry
• This can help manage load and improve overall system resilience

About Booking.com API:

The Booking.com API is a comprehensive interface designed to seamlessly integrate the extensive functionalities of the Booking.com platform into third-party applications. It allows developers to access a wide range of services including property searches, booking reservations, price retrieval, and accommodation availability. By leveraging the API, businesses and developers can enhance their travel-related applications with real-time data on over 28 million listings, spanning hotels, apartments, vacation homes, and other unique properties globally. With robust endpoints and detailed documentation, the Booking.com API offers flexibility and scalability to cater to diverse business needs, ensuring a smooth user experience. It supports various programming languages and includes advanced features such as filtering options, real-time booking confirmations, and multilingual support, making it an ideal choice for travel agencies, online travel platforms, and hospitality management systems looking to expand their offerings and improve user engagement.

About Lunar.dev:

Lunar.dev is your go to solution for Egress API controls and API consumption management at scale.

With Lunar.dev, engineering teams of any size gain instant unified controls to effortlessly manage, orchestrate, and scale API egress traffic across environments— all without the need for code changes.

Lunar.dev is agnostic to any API provider and enables full egress traffic observability, real-time controls for cost spikes or issues in production, all through an egress proxy, an SDK installation, and a user-friendly UI management layer.

Lunar.dev offers solutions for quota management across environments, prioritizing API calls, centralizing API credentials management, and mitigating rate limit issues.