A Song of API And Fire

Emily didn't expect much excitement at her day job. She worked for a health insurance company, so most of her projects were pretty routine enterprise-level things: hooking up the accounting software to the billing software, managing mailing lists, the usual stuff. When she was given a minor role on a large project, she never dreamed it would be any different than the usual fare. She was unprepared for what she received: Project Aegon.

Insurance companies reach out to people a lot: direct mail advertisements, mail to their subscribers, telemarketing phone calls, and the like. Before Project Aegon, each of the contact lists was housed in a different little kingdom. Subscriber information in the North, direct-marketing addresses in the Riverlands, and so on. Project Aegon was meant to unify these all into a single central repository, and that meant conquering several different application datastores and mastering them all in one location, establishing a new primary source of intel in King's Landing.

Emily's part in this large debacle was Dorne, the email provider: think Mailchimp, but more enterprise. Dorne was an important target for the migration, as it controlled most of the company's outgoing email. However, it was a difficult target to attack strategically, as it used guerilla warfare in the form of a terrible API to protect its information. The API used XML, but it wasn't SOAP, preventing Emily from using a simple library to interface with it. It was far from REST as well; there was no rhyme or reason to the endpoint design, as it had grown "organically" over the years.

For a time, Emily thought she was making headway when she discovered the existence of an API for querying the SQL directly. Surely that would be an easier method of obtaining up-to-date subscriber information? Then she saw the example query. She didn't make it any further than the following before bailing:


<LEFT_PARENS><LEFT_PAREN>(</LEFT_PAREN></LEFT_PARENS>

Bound and determined to conquer Dorne, Emily finally found some luck: the batch API. She signed up for a developer key, providing her company email address, and plugged away at the thing until she got it to do what she wanted. The files it generated were massive XML files, but she wrote a shim that received them via SFTP once a day and provided a REST API to query against the data so the rest of the Aegon development team could interface with it. Satisfied, she washed her hands of the seven kingdoms and moved on to Project Braavos.

Years later, while working on Project Ibben, she received a furious email: Dorne's reports were clogging up the system, hogging resources and slowing business functions that shared a server to a halt. Confused as to why she was even being emailed, Emily took a look. Sure enough, the daily process had been run 6,000 times in the past 4 days, with 4,000 more pending in the queue.

A little digging revealed how her name got attached to the project: the current devs were still using her personal API key in the test region. Furthermore, they'd been having a problem, so with the test region still hooked up to the production Dorne server, they had bumped up the poll frequency to every 30 seconds to look for a sporadic issue. Emily was forced to manually cancel and delete all 10,000 batch requests to clear the queue. Once finished, she pulled her API key for good measure. It was time to play a little game with the current devs ...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!