November 13, 2013
Or my APIs have seen the coming of the Lord!
APIs – Application Programming Interface have been around for a very long time. These days it seems you cannot walk or speak about Travel without the techies starting to talk about this API or that API.
The world now requires a different skill set. The ability to reuse and repurpose code and the explosive growth of Apps has fueled the change. But Travel remains something of an enigma. The category is usually marked by 2 seperate characteristics in Technology:
1. It is very possessive of its data and its “Intellectual Property” I would hazard that only Telecoms is more paranoid and restrictive.
2. it has the clunkiest back end systems with way too much out of tech technology. Legacy applications abound everywhere. Some technology that is so old it has been retired by their creators (many of whom are actually retired or even dead).
I can recall even as recent as a few years ago that a senior representative of a GDS was extolling the fact that to connect to their API required a monthly subscription of $1000 and a minimum one year contract before access was to be permitted to their very safe and secure system. And he thought that was a BARGAIN.
Happily today there are many APIs now freely available but the plethora of them is not helping. Most APIs are arcane in their flows and while they use common technology models and even some use standards the implementation of an API is anything but trivial. For many startups who look online and see the availability of many APIs it looks very easy. Don’t be fooled its VERY HARD.
There are a large number of pitfalls to watch out for. Let me give some of these as an indication.
Open Travel Alliance. The good standard for APIs in the Travel Industry (I will come onto Air in a moment). They dont have a formal test harness to validate the messages and as a result many business partners have developed extensions and resulting implementations are unique to those business partners alone. The amount of reuse for the next pair of business partner (with one of the original players) becomes hard. The individual players – typically supply owners or large agregators make the smaller suppliers and aggregators suffer by having to frequently implement unique versions of the APIs.
Work flow does matter. Remember at the back of many of these APIs are steam powered mainframe systems or mainframe work-alke systems still using arcane and cryptic interactions and logic. Many airline and hotel based systems still use embedded terminal commands to achieve completeness of the dialogue. Most mainframe based solutions still use session based controls and though these are fooled into looking like they are session less – this is done through the opening of the transaction and then the closing at the end, all of which adds time to the XML pair. Result performance suffers.
Air.. oh boy where do we start. The arcane world of the GDS system doesn’t really like the way that the LCC carriers use merchandising. At present the GDS mainframe based systems are trying to fix their legacy by fooling the solution to allow a merchandising based capability. Mostly this is accomplished through a bold on ancillary server either in-house (still a work in progress) or through a recognized provider such as OpenJaw Technologies or Farelogix. NDC should fix this but today there is a big debate going on in the DDX work groups about how to address different airlines merchandising and differentiation capabilities. One of the critical problems is (yes again) workflow. Do you merchandise before the PNR is built or after. A set of tricky questions indeed.
Thus for those trying to aggregate solutions for a shopping system this can be really hard.
So as I would like to say BEWARE.
APIs APIS everywhere and not a drop to make work… easily. (With apologies to Samuel Taylor Coleridge for butchering the Ryhme of the Ancient Coder).
Here is a good link to a story you should read. http://www.infoworld.com/d/application-development/the-risks-and-rewards-of-the-age-of-apis-230600?source=IFWNLE_nlt_daily_am_2013-11-12