Documentation

Cache build

Cache build best praxis

If in your user frontend search times are crucial we recommend to cache at least some information.

Remmenber the basic static data you must cache and update each month in your database:

Languages API mapping codes, must be stored (at least the used ones).
Destination mapping must be stored, using countries request and for each country get destinations in order to have full HB countries destinations mappings.
Currencies mapping must also be stored in case of working with multiple currencies or if you are developing for a platform.
Segmentation can be stored if needed, or displayed from real time requests.

Note, details request are NOT allowed to be used to build cache, only on customer demand.

Avail data is cached on HB side but detail requets are checking in real time with suppliers, causing a lot of traffic to suppliers worsening response times for all customers of even causing some suppliers to close our direct connection.

Remember:

Caching data using detail requets will not be approved in certification process.
Displaying always the LIVE responses data replacing the cached information, as some changes may occur since last caching.
Maximum allowed search dates range is of 60 days.
Custom caching can be made, for example lazy cache could be also a valid solution.

Depending on needs different caching solutions could be used.

See different caching flow :

We can split the request of two types :

Requests to build cache / cache data
And LIVE requests on final customer demands.

0. No cache (all on demand requests) :

1. Make an availability in real time for desired destination code and paxes ages. (display all from real time).

2. Details of selected activity from results to get ratekey display details data.

3. Confirm.

Just languages and countries mapping need to be cached, operational days, full content, questions, pricing and all needed will be from LIVE responses.

Good for clients that can’t expend much time/resources in the development.

The inconveniences is depending on HB server load and is limited of the request per second quota.

1. Basic list with box office amount prices. Real time availability/pricing/content

1. Make portfolio avail request for each interested destination, in order to obtain all activities list and box office amount.

2. Show activities basic list. Activity name, modality and box office amount.

3. Once interested in one, make details of selected activity, display accurate pricing, operational dates, remarks and full content.

4. Confirm.

Just activities names/codes, modalities names/codes, operational dates, box office amount pricing and few more details need to be cached, all content is displayed from LIVE responses.

Could be valid for travel agencies that don’t need to have a full listing, once client is interested in one product, make LIVE details request go have full information.

Good for fast UI, minimum data caching (just portfolio).

The problem is that the prices are box office, not accurate ones, no images.

2. Basic list with box office amount, full content. Real time availability/pricing/content :

1. Make portfolio avail request for each interested destination, in order to obtain all activities list and price from.

2. From the activities portfolio results, for each 100 interested in, make an content multi request by service codes each time for 100 services, form responses cache all content.

3. Display listing to final customer, with price from.

4. Details of selected activity display real pricing availability.

5. Confirm.

Full content is cached, also portfolio basic information such as activities names/codes, modalities names/codes, operational dates and box office amount pricing.

Could be valid for travel agencies that don’t need to have final pricing in the listing, once client is interested in one product, make LIVE details request go have full information.

Good for fast UI, Full content available

The problem is that the prices are box office, not accurate ones, no images.

3. Full portfolio, full pricing and content. Real time check and confirm :

1. Make portfolio request for each interested destination, in order to obtain all activities list.

2. From the activities portfolio results, for each 100 interested in, make an availability request filter by service code with OR combination each time for 100 services, form responses cache all the needed information, dates, pricing, content…

3. Display listing to final customers from cached data.

4. Once client is interested in one service, make a details request in order to get ratekey and show updated data.

5. Confirm.

Display listing to final customer form cached data.

Once final clients chooses a service form the listing, display all cached detailed data (modalities/sessions/languages, operational dates and full content).

Meanwhile (displaying all cached detailed data to final customer), you can:

- Send a details request in order to update all information form LIVE response.

- OR wait final customer to select (modality, date, session or language) then, send details request in order to update all information form LIVE response.

Good for fast UI, Full content, pricing, operational dates basically all information is cached.

Recommended for clients that wants the fastest UI as possible or have high customer requests per second.

Practical flow example:

See an example of how make full cache (we assume you already have basic maping done, as counties, destination, languages...)

1. For each interested destination code (PMI) request basic portfolio:

GET https://api.test.hotelbeds.com/activity-cache-api/1.0/portfolio?destination=PMI&offset=1&limit=1000

You cache all basic information.

Remenber to get al the records, the response header "X-Total-Count" will the return the total number of records.

2. For each activity code up to 100 request availability:

You can request al the returned ones, or just the desired ones.

{
    "language": "en",
    "filters": [
        {
            "searchFilterItems": [
                {
                    "type": "service",
                    "value": "E-E10-A0AANO0335"
                }
            ]
        },

        /*!!! UP TO 100 per request !!!*/

        },
        {
            "searchFilterItems": [
                {
                    "type": "service",
                    "value": "E-E10-NTASVQMONU"
                }
            ]
        }
    ],
    "paxes": [
        {
            "age": 30
        }
    ],
    "from": "2021-05-11",
    "to": "2021-05-22",
    "pagination": {
        "itemsPerPage": 100,
        "page": 1
    },
    "order": "DEFAULT"
}

The response will return all data of each available activity so you can build the complete cache.

You just need to display cached data to final customers until they are interested in one particular product, then you must make a details request in order to obtain valid ratekey an updated data, and finally confirmation.