Guest Post: How to shed light on the ‘dark art of API connectivity’

Comtec’s Jon Pickles explains how light can be shed on the ‘dark art of API connectivity’, having raised the issue at WTM.

Comtec’s Jon Pickles explains how light can be shed on the ‘dark art of API connectivity’, having raised the issue at WTM

In a world where technology is being used more and more to drive sales and provide customers with as much content and flexibility as they demand, how do we get that content quickly to market?

Most suppliers use proprietary XML interfaces (APIs) to enable salessystems and web developers to connect to their products. But why should this connectivity be a black art and available only to the chosen few?

Travel technology suppliers such as Comtec have to do many things. We have to have a flexible sales product that facilitates a variety of holiday components, including packages, dynamic packages, tailor-made, flight-only, car hire and accommodation.

We also have to adhere to payment card processing rules and regulations (PCI-DSS) and other legal requirements such as Atol certification.

It takes us many days of development and testing to implement new third-party interfaces. This is because each one of the suppliers we connect to has its own bespoke interface.

We know a hotel bed requires a duration, a passenger configuration, a room type and extras like fruit or a bottle of champagne. So why do we have to write a specific interface to add a new bed bank or low-cost flight API? Surely the requirements are the same?

The problem is that any standard has to be adopted to become a ‘standard’. The Open Travel Alliance has tried to set such a standard. The problem is that only a few suppliers have implemented it, and then, because it can often fall short of requirements, they have to add their own set of extensions to support their product.

This then makes the standard non-standard, and so it goes on.

Image credit: xkcd.com

So, what do we have to do to become standard? We have internally tried to write a standard interface and originally started to use the Open Travel Alliance format, but quickly realised only some of the third-party suppliers’ product would be supported by it.

If there were an adopted standard we could implement integrations quickly and would probably only need to test the interface rather than analyse, write and test each bespoke integration.

Mapping suppliers are providing standards such as KML, GPX and KMZ to enable developers to integrate mapping quickly and easily.

Apple iPhone developers can use standard modules and tools to mash up maps, location and other services using nothing more than “drag and drop”, so why not supplier APIs?

Each week I get suppliers asking us to integrate their product: we look at their interfaces and realise it’s going to cost us to develop the integration.

We then have to work up the return on investment to see whether any time spent on the integration is going to provide us with a good return. If not we might never integrate the supplier.

I have asked three suppliers in the last week if they are Open Travel Alliance-compliant: one said “what’s the Open Travel Alliance”, the other two said no.

So, it is here that I have stumbled on the answer. It’s the suppliers that need to get together and make sure their API is based on a standard.

Suppliers can then give us a call and we can get ourcustomers to sell your product quickly and easily. If they don’t have an appetite to do this then perhaps we can do this for them.

Now, let’s talk about web browser standards.