The term API (Application programming interface) is not new, basically a defined access to a set of methods, subroutines and data-types made available by one component/service to be used/consumed by another component or application. You can think of API as the car manual and the library being the engine under the hood.
Since the early days of tinkering with the Windows DLL hell more than 20 years have passed, we have better tools and standards by now. In the space of native apps for Windows, Android and iOS we still work with libraries and SDK’s (still can be challenging when resolving dependencies and deployment).
In the world of web applications today we look mostly at RESTful Webservices responding in JSON or XML, a rather straight forward implementation, the only complexity depends on the authorization mode or the mapping of attributes. A lot of websites, portals, services or products expose their WS for usage by third parties, from Salesforce, Ebay, Amazon to Twitter and infinite more. While these mentioned samples operate independently or work as standalone services there is not much need for standardization of the payload, aka the structure of attributes, naming conventions etc. For others business domain there is a need of standardization of such, despite the availability of AIDX, AIDM and a few more data exchange models, there is no standard widely used in the (public) WS space in aviation.
I have to highlight in ACI ACRIS a Semantic Model is being actively developed and the Open API Shop exists as project as well.
I researched what webservices are currently offered to the public by airports and airlines, excluding the API’s of system vendors and travel platforms.
So far I found these webservices (last update 2018-07-06):
Airline
International Airline Group British Airways, Iberia, Avios |
https://developer.iairgroup.com/ |
Lufthansa | https://developer.lufthansa.com/ |
Airfrance, KLM | https://developer.airfranceklm.com/ |
Alaska Air |
https://developer.alaskaair.com/ |
Transavia | https://developer.transavia.com/ |
FlyDubai | https://developer.flydubai.com/ |
Virgin Australia |
https://developer.virginaustralia.com/ |
Ryanair | https://developer.ryanair.com/ |
Turkish Airlines |
https://developer.turkishairlines.com |
Airports
Schiphol Airport |
https://developer.schiphol.nl/ |
San Francisco Airport |
https://www.flysfo.com/api |
Frankfurt Airport |
https://developer.fraport.de/ |
Svedavia Airports |
https://apideveloper.swedavia.se/ |
Others
FAA US |
https://app.swaggerhub.com/apis/FAA/ASWS/1.1.0 |
Flightaware |
http://flightaware.com/commercial/flightxml |
The usage terms and price models vary but basically all give some kind of developer access to evaluate the services and data at no cost.
To compare a few of the services using a flight status related call, omitting the authentication. The lack of standard, putting aside JSON response format and date format, is quite obvious. It might not be relevant in the space of individual apps to have the same response format, but if you want to combine data from various sources you have to handle the formats separately. Even the request format with the query parameter differs.
British Airways
https://api.ba.com/rest-v1/v1/flights;departureLocation=FRA;startTime=06:00;endTime=11:00
Swedavia Airports
Lufthansa
https://api.lufthansa.com/v1/operations/flightstatus/LH778/2018-07-13
I also tried with RyanAir (still waiting for approval to get api key), Turkish Airlines (no flight status API), Schiphol (no webservice test available on the website).
Image: Creative Commons, Robert Yarnall Richie Photograph Collection, “Models with Oldsmobile Automobile, Lockheed 10B Electra, Delta Air Lines, 1940”