7 Things to Consider When Designing a Travel API

Leading travel companies are increasingly broadening their distribution channels by building platforms that enable partners and customers to connect and access their inventory and sales systems via application programming interfaces (APIs). APIs are the tools powering many of today’s mobile and Web applications. They work by giving developers the relevant code and building blocks they need to create new applications and integrate new sources of data into existing apps and services.

Here at Triometric we work with many online travel companies and see lots of APIs: all doing essentially the same thing, but all quite different in their implementation. We are in the business of analytics. Specifically translating raw message streams into business intelligence that supports critical decision making - in near real-time. We see how some APIs lend themselves much better to analytics than others. Analytics play a crucial role in web services monitoring and ensuring the success of API programs. Some of the biggest B2B online travel companies use our analytics platform to monitor and analyze their API traffic and ultimately derive insights to drive their business.

In order to analyze an API transaction, information is often required from both the request and the response. For example, when analyzing product availability (such as hotel rooms or seats on flights), you want to know what a user searched for (the request) and whether any products were returned (the response). This traffic flow between Web servers typically takes place using XML or JSON-based payloads. Both are tree-based structures: transforming tree-structured data into charts and tables is one challenge; matching two trees (the request and response) of different shapes is a bigger challenge. Fortunately there are ways to simplify the problem.

Deriving business intelligence from search and booking streams and transactions is an important differentiator for online travel companies. So analytics play a crucial role in ensuring the success of API programs, but getting those insights does not happen by accident. A vision of the insights that are possible from the API should already be present at the design stage. This article presents 7 key considerations that should be borne in mind during the design phase of an API to make analytics easier. This article refers to XML, but applies equally to JSON.

1. Standard Format for Each Document Type

Not only does having some level of consistency across all document types make it straightforward to find certain pieces of information in all transactions (e.g. user names, preferred language, error messages), it also aids analytics by having as much data in the ‘same shape’ as possible. For example, having the same data relationship between the search criteria used in Search requests and in Booking requests makes it easier to assess the conversion ratio for the various criteria.

2. Atomic Values

In a software or database design context, 'atomic' means a field or attribute should NOT be composed of multiple values. In other words, a field should not hold a delimited list of values.

For example, each product code should be in a separate field e.g.

<code>abc</code><code>def</code>

rather than a list within a field e.g. 

<codes>abc, def</codes>

Non-atomic values can be problematic for analysis: they need extra processing to be meaningful. We sometimes encounter comma-separated lists of product codes or similar, which need to be split before any analytics can be meaningfully performed. Without this separation, questions such as “Show me all requests for product code 123” need to be expressed as “Show me all requests whose product code list contains 123”, which is not only more expensive to process, but may also include other values such as 1234.
 

Richard Baker is the Technical Director at Triometric, a company specialising in the performance monitoring and business intelligence of API search and booking traffic for online travel companies.

Comments