As a senior dev at G Adventures, I’ve had the great opportunity to work on the REST API here. This post is the first of many detailing how we got to where we are.
Our core business at G Adventures is small group travel, a social enterprise that strives to show the world to our travellers and in turn improve both the lives of our travellers and the lives of those who live at the destinations we visit.
As one can imagine lots goes into planning a tour on the other side of the planet to ensure everything goes smoothly from a day one. As our business grew so did our various systems. Eventually, it was necessary to have one common interface (or one common language) that our systems could use to talk to each other. We chose REST API which stands for Representational State Transfer and API stands for Application Programming Interface.
We use this interface to expose our business systems to developers both internal and external. As an example
contains all kinds of useful details about our Peru Panorama tour, including things such as tour’s itinerary or links to specific departures.
This means of communication has been a huge factor for our business growth as it allows our partners to integrate with us in a much more cost-effective way (in the past booking a tour with us required the use of a specialized website and often even a phone call). With REST API it’s a few HTTP requests instead.
Internally it allowed us to integrate our various systems and hide implementation details so that application developers no longer have to have intimate knowledge of every single system that we have. Once a developer becomes familiar with the REST API they can use any of our systems in uniform fashion whether they are interacting with our inventory management system or our customer management system (CRM), or anything else we expose via API.
The existence of this uniform interface even allowed whole new applications previously not possible. Such as our automated email engine or universal search functionality.
Not long after we launched the API did we discover the need to also be aware of when things change. E.g. if the above Peru Panorama trip no longer starts in Lima, we need to notify the website, our booking engine, all our API clients, who often display the trip on their own websites.
One way to do this is for every developer to check the above URL at specific intervals (polling). But this isn’t really a good strategy because we run around a thousand different tours with most of them having at least one departure every 10 days. That is a lot of URLs to poll.
Webhooks (don’t call us we will call you)
Webhooks can be compared to push notifications and are a simple mechanism to inform our API users when something in our ecosystem changes. In other words, rather than our users always checking the above URL to see if anything changed we will let everyone subscribed know if there are changes to the Peru Panorama tour.
These webhooks enable a universal mechanism of notifications that various business units use to obtain relevant info as soon as possible. Side effects included us being able to keep a replica of our data that we used for uniform searching and caching to increase functionality and responsiveness of our API.
Our external partners can use the webhooks to observe our inventory, watch for special deals or be immediately informed when anything happens on a booking they made with us.
I am proud of what we were able to accomplish with our API, but in my next installment I’ll get more technical as the story of REST API at G Adventures is far from finished.
Stay tuned.
Keep following us on Medium and Twitter for more snippets of the Tech world according to G!
Want to help G Adventures change people’s lives and travel the world? Check out all our jobs and apply today.
Latest comments (0)