Emergence of APIs in travel ecosystem

Transcription

1 White Paper Emergence of APIs in travel ecosystem Introduction Application Programming Interface (API) has been a buzzword for some time now among technologists. Numerous strategies for designing efficient APIs are available and so are many business models. The need and focus on APIs has led to the emergence of API consulting companies which specialize in evangelizing and designing APIs to one s needs. In short, the core problem statement that APIs address is intercommunication between two systems and this problem statement is definitely not a new one but perhaps one of the oldest in the computing world. So, although multiple systems communicated with one another in some form or the other, the emphasis on strategizing API-based development started around 2005 and has gained a lot of momentum since then. Some of the factors that acted as catalysts to this phenomenon being: Increasing enterprise nature of businesses. Explosion in the usage of mobile or portable devices, social networks, and cloud, among others. Need for scalability of applications for multifold increase in user base and partner systems. Travel and hospitality industry is no exception to this phenomenon. Gone are the days, when the only medium to book a travel itinerary was a Global Distribution System (GDS) green screen. An increasing number of online travel agencies (OTAs) and advent of alternate GDSes and distribution systems has resulted in a complex network of systems. They help end consumers to make travel plans, enabling them to browse through rates of various travel products in real time, and make bookings at their fingertips using any type of device, be it a conventional browser or on a fancier portable device. 01

2 APIs in travel and hospitality industry API enthusiasts would already know the significance and the amazing success stories of leading API providers such as Google, Twilio, NetFlix, NPR, Facebook, Twitter, and Amazon (AWS), among others, which have changed the way applications are being built and used. The travel and hospitality industry has adapted to the same trend. At Cybage, we have done a majority of work for our clients that involves building connections with various systems ranging from major GDS (Global Distribution System), ADS (Alternative Distribution System), CRS (Central Reservation System), switches, PMS (Property Management System), booking engines, ticketing engines, pricing engines, direct connectivity adaptors for LCCs, back office systems, CRM, and many others. Complexity of building these connections was always varying. Legacy systems such as GDSes; pricing engines such as SITA, which made use of electronic data interchange (EDI) formats such as Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT), Data Interface Record (DIR), Passenger and Airport Data Interchange Standards (PADIS), and Teletype messaging formats of Type A and Type B were formerly prevalent and widely adopted. We observed a significant turnaround in the adoption of the modern day HTTP, XML, and SOAP-based web services with the emergence of messaging and communication standards (such as OpenTravel, Open AXIS, and Hotel Technology Next Generation (HTNG)) that changed the landscape of communication with an XML schema based approach allowing many travel players to follow a similar contract between their systems. This change in turn forced legacy GDSs to provide interfaces with the modern day technology stack as it was the need of the hour. Although HTTP+XML solved a lot of problems from the communication standardization perspective and reduced the time taken to build and consume any service significantly (for developers), need for a lighter and simpler communication medium still remained. Emergence of HTTP based Restful services using JSON messages was a significant leap and contributed a lot to the emergence of API based models. Developers from various communities be it Java, Open source, or Microsoft stack were only interested in the HTTP URLs and nothing more. The mantra for API-based systems being, Expose your business assets via an HTTP URL, provide the resource as JSON or XML, and let all other complexities be encapsulated under this layer. ProgrammableWeb.com which provides an exhaustive directory of APIs and Mashups from all over the world contains around 227 APIs (as on March 2014) under the travel category which includes leading travel players such as Expedia, Booking.com, TripIt, Kayak, and Hotels Combined, among others. 02

3 The following are some key stats for APIs built for travel-related systems (Source: ProgrammableWeb.com): PROTOCOLS USED BY TRAVEL APIs Count Others JavaScript XML-RPC SOAP REST DATA FORMATS USED IN TRAVEL APIs Count Others XML JSON Keys to designing efficient APIs Designing efficient APIs is an exhaustive topic in itself and it is something that is not subjective to travel APIs alone, but applies to any type of API. We do not intend to elaborate detailed explanation on design strategies here. What we intend to highlight are the key factors that must be considered during the designing of any API. Ease of use One of the most important factors for any API is how easily one can understand it and put it to use (in developer parlance, how fast can I start to code with an API). For this, the API has to be designed in a succinct manner with clear uniform resource identifiers (URIs) and noncomplex data structure (either JSON or XML). The key to easily understanding an API lies in its simplicity. In case complexity cannot be averted, the API should be accompanied with a how-to documentation. Almost every developer who has worked on a complex connectivity at Cybage has rated lack of good documentation as the prime factor. 03

4 Target audience An API should be designed with a target audience in mind. Almost every API produced will be consumed by systems built by developers. The new system will be built for a specific type of end consumer. So it is important to keep both the developer and the end consumer in mind while designing the interfaces for the API. In enterprise level organizations, where multiple systems interact with one another, private APIs form the crux of internal applications. In this case, the target audience will be developers from one s own organization, but building systems for, maybe, a different department. So, involvement of business owners and developers during the design phase is the key. Public APIs on the other hand pose a different challenge, as one has to preempt its usage by external developers and one has to know the return on investment it brings to the organization. Technical considerations As mentioned earlier, about the changing trends in technologies used for data formats and communication in the travel industry, we can understand that APIs are moving to the Restful way significantly. Pure Restful services are being replaced by Pragmatic REST (where the response returned by the server for a requested URI intuitively tells the user about what can be done further (they are easy to learn and navigate from a developer s standpoint). Statistics collected from Programmable Web clearly displays that XML is the preferred data structure over JSON for travel APIs as it was the preferable data model for Restful services, but with increasing number of tools and frameworks available around the JSON structure, JSON is preferred for newer APIs, due to its lighter weight and flexible model. The non-functional side of APIs forms another key factor, one of it being security. OAuth protocol allows introduction of token-based authentication encapsulated under the HTTP headers and it is being widely adopted by public APIs and there is a significant acceptance of the same among the developer base. Conclusion As the travel industry adopts the latest trends from the API world, it becomes important for the existing key players to adapt to these trends if they have already not done so. The following is the key to building successful APIs: Evangelizing private APIs in a way that they help build strong internal systems. Evangelizing public APIs in the developer community to build applications that help in better distribution of travel data inventory, rates, and availability, among others, and innovative products that work seamlessly and in turn enrich the travel ecosystem. 04

5 Resources 1. O Rielly APIs: A Strategy Guide By Daniel Jacobson, Greg Brail and Dan Woods Cybage Software Pvt. Ltd. [An SEI-CMMI Level 5 & ISO Company] HQ: Cybage Towers, Survey No 13A/ 1+2+3/1, Vadgaon Sheri, Pune Tel: Fax: Pune Hyderabad Gandhinagar Seattle New Jersey San Francisco Atlanta Austin London Frankfurt Amsterdam Sydney Cybage Software Ltd. All rights reserved. 05