By Jacqueline Mak, Software Architect, and Gustavo Terraciano, Manager, Software Engineering, EdgeCast Portals Team
Every day, our Verizon Digital Media Services REST APIs get around 1.5 million requests. Roughly a third of those are customer purge requests. In order to handle this enormous (and growing) amount of data, our technology has to constantly evolve.
A critical part of this scaling process is deploying high performant hardware. At the same time, we are improving our network’s ability to respond more quickly to API requests, so more calls can be processed.
The move from SOAP to REST API in late 2009
As a means to offer a framework for data integration to our clients, in 2006 we started providing SOAP (Simple Object Access Protocol) to retrieve account information, to manage CDN configurations, and to receive reporting information.
Back then, SOAP was the industry standard for the Microsoft stack and provided a secure way of automatically exchanging account information between us and our clients.
Limitations of SOAP
Since SOAP relies on a very strict XML specification, we experienced several integration issues with clients that were not using Microsoft technology. SOAP libraries for different technologies were not standardized, which resulted in problems for our clients that were using languages such as Java (in this particular case, we couldn’t parse and serialize a SOAP envelope to Java).
This resulted in most of our customers asking for libraries and code samples to integrate with our systems and figuring out how our documentation applied to their technology and library.
Another limitation was SOAP’s heavy use of data and its extremely verbose XML structure. As our network traffic and client base kept growing dramatically, working with a comparably slower format became an obstacle to optimizing our purge performance.
This led us to believe that we needed a lighter, technology-agnostic solution.
Transition to REST
We started fading out SOAP in late 2009 in favor of REST, which at that time was rising in popularity among developers. Doing this with hundreds of client accounts wasn’t an easy task, as customers had to modify their codes.
To ensure a smooth transition, we had selected customers to test the new standard while releasing information about how to call the API.
During the transition, one main advantage of REST became immediately apparent: having one standard that’s easy to consume. Whereas SOAP requires a XML schema (specification what SOAP package contains), we don’t need to provide instructions on how to read REST messages. This has lead to a decrease in requests for code samples over time; the overall ease of integration for our clients has improved.
REST also supports JSON as communication object. This allows us to accomplish more with less resources, making processing times faster than with SOAP calls — a critical advantage for web performance company such as Verizon.
Today, we integrated 250 customer facing APIs and 50 internal facing APIs (e.g. for our mobile real-time stats app). And while REST has proven to be as secure as SOAP, we’ll keep working on making further security enhancements to our REST API.