The travel industry has a tendency to enjoy bashing itself for everything poor and bad its sees happening, sometimes looking outside to bring a fresh perspective.
But most other verticals are only just scratching the surface about the idea of a world of machines interconnected and talking to each other.
Everyone is now running to open up APIs, thinking they’ll strike gold (users, traffic, sales, etc), just to realize, well, providing an API is not without consequences.
Providing an API means someone else will now depend on your service.
In the past few years, some companies have emerged whose business is specifically about helping other companies managing APIs: Apigee, Mashape or Mashery, to name a few.
In 2011, you even get Forbes talking about APIs!
Interestingly, the travel industry has been running machine-to-machine communication for decades. It started back in the 1960s with teleprinters on paper tapes and AIRIMP standard messages, up to today’s high-speed links using OpenTravel schemas over the web.
So what can the travel industry teach the rest of the world about its decades of experience with APIs?
1. The obvious: APIs must be well documented, fast, reliable and secure
I am happy to use your great service into my site, but I have many other things to do and can’t spend days reading manuals and trying to make it work. Keep it simple and clear.
I need very few necessary things: what are the input and output parameters, their formats, default and possible values. The best is to give me sample requests and responses and sample codes or libraries that I can start with. Screenshots or a demo site can be nice too.
If I am building a site on top of your API, I need to make sure my site’s performance will not suffer because your API is slow or buggy.
Make sure you’ve run stress test by shooting transactions and simulating peaky traffic scenarios.
I’ll probably require a written Service Level Agreement (SLA) so that we both know what to expect. If I am a big partner, I’ll probably ask you for your stress test results, and I might even have my own teams shoot in some stress tests.
If I am a very big partner, I’ll probably also have my security team attack your platform before I’ll approve it for production. If you already had third party security audits performed, it’s a good sign and it might speed up my decision process.
2. The less obvious: APIs must be testable, measurable and loggable
If I understand how your API works and I trust it’s not going to impact my site, I am ready to integrate it.
I am not perfect, I will have bugs while I develop, and I don’t want to have my infinite loops booking flights for a full week (it has happened).
Please give me access to a test system (or sandbox) I can use to write and test my application without impacting real production environments.
This is an absolute necessity if your service involves locking live inventory or payment transactions. Plan to have test keys, test names and test card numbers available.
In general, I’d like to get a regular (weekly, monthly) report of all transactions I’ve generated, what are the most frequent calls, peak days/hours, total amount of data transferred, uptime, distribution of response times.
Average response time is not good enough: I want to know the response time for 90%, 95%, 99% of my transactions, and how this compares to the Service Level Agreement you’ve committed to.
In case something strange happens in production and we don’t agree about a transaction, I also need you to show me traced logs of the suspicious transactions so that we can understand who’s done something naughty: in other words, my code or your code.
3. The even less obvious: APIs must be supported, “versioned” and maintained
Great, it looks like you’ve got everything we need for a smooth operation. But what will happen in case of production problem? You have to understand that my service could go down completely because of your API.
Are you actively monitoring production status, with scripts testing real scenarios?
If you go down, who do I call? You should have a service center available for your API clients, according to your service quality (24/7 for anything mission critical, less can be acceptable if your service is a minor feature of my platform).
In case of faults, you must keep me up to date as frequently as possible. Use some kind of status notification system, obviously not hosted on the same server.
If everything is under control, let’s go. By the way, now that I spent several days/weeks/months of resources to integrate your service, don’t even think one second about launching a new version and forcing me to redo all the work.
It’s great that you’ll have a new version, but make sure it doesn’t change anything to my current version.
Leave me enough time to migrate, and remember to maintain my version too. A typical migration time in the travel industry is six months from the moment your new version is available, and it’s common to maintain old versions for two years.
Key takeaway: you must be dependable
It’s great to open up your APIs and provide useful data services, but it’s not enough.
If you want your service to be useful and add real value to your clients, you must put yourself in their shoes and literally run for them. If they’re dependent on you, you must be dependable.
Related posts:
About Daniele Beccari
Some great points and guidelines for anyone looking to create, operate, maintain or connect to an API. Great article Daniele!
However, having worked with many travel API’s from GDS, to tour operator systems to the massive custom infrastructures that OTA’s have built (and now struggle to maintain) I’m personally not sure that much of the travel industry takes a great deal of notice of these obvious guidelines
Thinking back to when we I managed implementation of an XML gateway on top of a Cobol reservation system, none of this is easy in travel and the complexity you find in travel operations online is second to none. That’s why I enjoy working in online travel.
So, I actually think the travel industry have a lot to learn from your article above and I’m not convinced that travel is the best example of how to operate an API properly.
Travel is though, probably the best example of complex data interchange between multiple platforms, technologies, suppliers and formats that you will find online (except maybe some financial services).
Should clarify; there are some travel companies with good API’s and good practices but also a heck of a lot who haven’t…
Steve – yes, none of this is easy, and it can be costly over time.
If you take GDSs, who are basically big API switches, they spend tons in maintenance on all sides.
I think it’s part of the reason they are slow, but also difficult to bypass: it’s easy to implements one direct link, it’s not easy to maintain 10 direct links (let alone 400).
I’ve seen many travel co’s doing it right, many others starting somewhere and improving along the way, and many still sitting around and wondering what to improve.
Good summary Daniele. I’ll keep a note of this article to refer people to in the future when they start bleating on about APIs
In your opinion, what are the good APIs and what are the bad ones?
From what I’ve seen, travel API technology is far behind the great APIs of today (e.g. Twilio and Stripe). Admittedly, I’m just getting started, but my team is planning to build our own REST API between us and the GDS, so our application will never directly make XML requests.
Key Improvements:
1. Get off XML, it’s too clunky for no real reason.
2. Make documentation actually public. I hate having to make weeks of phone calls and signing NDAs before seeing the technical specs of an API.
3. Make onboarding easier. Webservices seem to be at the bottom of GDS priorities, and finding the right person to talk to is extremely difficult.
4. The pay to play model doesn’t make sense for developers. Upfront costs ranging from 5,000 to 75,000 are hard for startups to stomach, especially when it’s unclear what exactly we’re paying for. “Initial Set Up Support” should be provided through documentation, not payroll hours.
Hi Colin,
GDS APIs are a particular case (as usual).
Most people fail to understand that access to any booking API gives the power to freely book live inventory, seats on hundreds of airlines, hotels rooms and other services. A minor bug could have enormous financial consequences for all parties involved (and it does happen). It’s far from Twitter.
There needs to be a rather strict API management process.
While I fully agree that GDS APIs can improve in terms of ease of use, documentation and onboarding, I think they’re doing a great job in many other areas – reliability, performance, maintenance, versioning etc. especially given the mindblowing volumes.
You can use ProgrammableWeb to find out more about lots and lots of APIs.
D.
Excellent points all around Daniele.
May I suggest a companion article, or perhaps a book, titled:
“What The Hell Does This Do?
The Joy of Exploring Poorly Documented APIs…
A Definitive Guide for Sado-masochists and Rube Goldberg Aficionados”
It fills me with joy to see so many articles recently about APIs. Great article Daniele, I think we have very similar approaches to APIs. One way to address all of the items you mentioned is to make your API part of your overall plan from the beginning rather than building it as an afterthought. For existing technologies this might be a bit more difficult, but certainly for start-ups it should be part of their DNA. At Rezgo, for example, we built our API first and then layered our booking engine on top of it. This did several things for us:
1. It made sure that the API was fast, reliable, and secure.
2. It allowed us to test the API on an ongoing basis.
3. It forces us to document it and ensure it is usable.
4. It forces us to continually update it because we can’t make improvements to the front-end without making improvements to the API at the same time.
This approach does add additional time to the development cycle, but it virtually guarantees that your API is going to be reliable.
Totally agree Steven, and it’s our approach at Flextrip as well. Eating your own dogfood, as it’s lovingly termed, has tremendous value in ensuring your API meets the goals it was engineered for. Wish more companies in general did this.