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:
Custom caching can be made, for example lazy cache could be also a valid solution.Depending on needs different caching solutions could be used.
Depending on needs different caching solutions could be used.
We assume basic data (such as countries/destination, IATA , currencies…) has already been imported.
We can split the request of two types :
For clients that don’t want to cache a lot of data in database.
The bad is that you don’t have any idea if the requested route is available or not either the pricing or content, just codes and names mappings.
For clients that want to have a more accurate availability without having to make any request.
The inconvenience is the update time and size of needed in the DB.
For clients that want to have complete accurate availability and all available content without having to make any request.
The inconvenience is the update time and size of needed in the DB.
See an example of how make full cache (we assume you already have basic maping done, as counties, destination, languages...)
GET 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.
You can request al the returned ones, or just the desired ones.
The response will return all data of each available serviceso you can build the complete cache.
You just need to display cached data to final customers until they are interested in one particular service, then you must make LIVE avail request in order to obtain valid ratekey an updated data, and finally confirmation.