Rail Europe needed to modernize its developer offering from a large set of overlapping and redundant SOAP web services, which exposed functionality from too low in the system stack, in extremely verbose payloads.
I conducted a competitive analysis of APIs to understand who was offering partner connectivity, what business capabilities they were making available, what technologies were in use, who their offers were aimed at, and how they were marketed, documented and supported.
I interviewed Rail Europe's current and prospective partners to understand their use of the previous platform and their experience of integrating it, but also to gain ethnographic insight into users themselves: how they thought about and understood rail travel concepts, how they preferred to work with APIs, and their development practices and cultures.
I introduced user-centered design concepts commonly found in consumer product design. From interview data, I created developer personas that helped us not only to understand what product we should create at the outset, but also to focus intently on the quality of the developer experience as we executed.
I worked with Sales and Business Development teams to understand how the API product could occupy a place at the heart of our business development strategy: to build our product strategy, identify our commercial objectives and derive the KPIs we would use to steer the product's development.
I advocated for several design and development patterns that were new to Rail Europe—a RESTful API architecture, design and specification using Swagger 2.0, automated acceptance testing of API builds, dogfooding, and use-case based production monitoring—that drastically reduced our time to market.
I worked closely with engineers to design core API concepts and author the API interface itself, aligning closely with our developer personas to ensure that domain concepts were exposed simply and logically in the API, and that we created suitable abstractions for problematic aspects.
I prototyped a developer portal based on SwaggerUI interactive documentation, that we ultimately used as our primary specification, ensuring that we had complete and accurate documentation for the API as soon as we were technically ready to launch. I extended the open-source Swagger Client and Swagger UI frameworks to better suit our needs.
My team delivered the first RESTful API dedicated to European rail travel.
The new API can be used to get from query to booked seat on a train in just three calls, with typical payloads weighing-in 10x lighter than the previous system's. Applications using the API convert better as a result of enormously reduced latency.
We dogfooded the API, by being the first production user when we built migrated our iOS app to the new platform. Our mobile users benefitted from the new API's full multi-channel capabilities, finally being able to plan and buy while moving seamlessly between Rail Europe websites, mobile apps, and contact centers.
Thanks to a far easier learning curve, we reduced integration time by half, and using industry-leading interactive documentation, we eliminated the need for dedicated integration support staff. It has never been faster or more cost-effective for Rail Europe to increase its market reach with new API partners.
Our robust deep-linking flow opened the travel metasearch market to Rail Europe: sites could now use a single API call to propose rail alongside flights, and reliably redirect customers to Rail Europe for seamless completion of their purchase.
A wider product offering is now available to all partners: algorithmic trip suggestions help customers discover new destinations, and an enormous range of tours and activities help customers get to know their destinations better, both increasing customer satisfaction and generating revenue.