Setting Up Travel APIs Pt 1

Hey, back to the point of this project, building a website that supports conventions and allows for a million users to hit it all at once because it's the biggest convention in the known universe! Enough with the DevOps logging and monitoring nonsense... back to the meat and potatoes of building a product.  Features!  We demand features!

(Despite that the big logging models are interesting...)

If we want people to buy a convention pass we also want to route them to a convenient and nearby hotel.  Setting up actual hotel programs with local hotels is largely out of the scope of writing a blog but looking into the developer APIs of various providers is not.  This goes into the world of having to partner with a SaaS.

I will simply walk my notes in putting together a solution.  Quasi real time... in text.  Exciting!

Pick an API Provider

Several of the API providers to hotel information have elaborate rules, partnering agreements, and requirements.  There are three of varying quality that allows developers to jump right in:

1. The Google Places API -- - which does all of the fun integration with google maps.  It brings up a nice list based on proximity and an integrated Google Map but doesn't allow for room and reservation information. Great for integrating with other things.

2. The Yahoo Travel API -- -- which looks a little long in the tooth and on its way out.  

3. The Expedia API -- -- which slices, dices, and allows listings to hotels although the site has to go through a complete review before Expedia will allow a production API key to their system.  They do post a fairly comprehensive list of criteria to meet.

This enormous list of travel APIs is available for perusal.

Expedia seems to want developers to integrate with their systems and pull their information to get the data flows through their systems.  Because of the sheer volume of their API documentation, due to it being XML/REST based, the ease of integration, and the availability of API keys -- developer access requires a sign up and then development can begin -- that one is the winner for pulling hotel information.  Project Butterfly will (in a vaporware sort of way) integrate with Expedia.

From a business development process there's likely a contract with an SLA attached that must be negotiated before a site integrating with them goes live along with their approval;  if Expedia goes down the system needs a plan or otherwise convention goers.  Also, there are enormous security requirements on both sides if booking actually works through our site, through Expedia (where they take a cut) and back again.   While Expedia can deal with the room booking via APIs, all communication must be secured via HTTPS.  Our site cannot keep credit cards information.  

Project Butterfly for now will only pull hotel lists and availability and post a link to send a user to Expedia to book their room (for now).  The site isn't ready to sell a pass so for now it will be only informational.

Looking through the Expedia API, one can request a hotel list based on a starting geolocation, page via cache on their side, proximity, rating, price list, room types available, room availability, etc.  

Part 2... will walk through implementation details and pitfalls with dealing with data from a 3rd party provider and the impact on the site.