{"id":7020,"date":"2017-11-06T17:55:05","date_gmt":"2017-11-06T22:55:05","guid":{"rendered":"https:\/\/rud.is\/b\/?p=7020"},"modified":"2018-03-10T07:54:16","modified_gmt":"2018-03-10T12:54:16","slug":"taking-a-shot-at-cdcfluview-v0-7-0-a-k-a-the-dangers-of-relying-on-hidden-apis","status":"publish","type":"post","link":"https:\/\/rud.is\/b\/2017\/11\/06\/taking-a-shot-at-cdcfluview-v0-7-0-a-k-a-the-dangers-of-relying-on-hidden-apis\/","title":{"rendered":"Taking a Shot at cdcfluview v0.7.0 (a.k.a. The Dangers of Relying on ‘Hidden’ APIs)"},"content":{"rendered":"

Unlike @noamross, I am not an epidemiologist (NOTE: Noam battles pandemics before breakfast, so be super nice to him) but I do like to find kindred methodologies in other disciplines to help foster the growth of cybersecurity into something beyond it’s current Barnum & Bailey state. I also love finding and exposing hidden APIs and especially enjoy killing Adobe Flash. How does all that relate to cdcfluview<\/code>?<\/p>\n

cdcfluview<\/code>?<\/a> was one of my first R packages. Someone, somwewhere, was trying to do something with Selenium to automate downloading of data from the CDC’s FluView Portal<\/a>. It was — and, some of it still is — a Flash-based site that locked up useful data behind application screens that did little more than burn ones retinas and force folks to keep Flash alive and, hence, their browsers insecure.<\/p>\n

Rather than let the requester suffer under the weight of a pretty significant external dependency, I used the magic of the browser “developer tools” inspector to see that it was making fairly innocuous and useful XHR requests for real data. The package sat on GitHub for a while and eventually made its way to CRAN.<\/p>\n

Times change and Flash is dying, so the CDC paid some serious benjamins to have the site re-done in HTML, replicating the horrible UX and terrible visualizations (so. many. pie. charts.). Said revamp also caused changes to the back-end APIs and forced breaking changes. Craig McGowan jumped to the rescue and fixed some core functionality issues, but so much changed — and so much was added<\/em> — that I felt it was time for a modern re-write of the cdcfluview<\/code> package.<\/p>\n

This is a pretty solid, real-world example of how dangerous it is to rely on hidden APIs. If Craig hadn’t both notified me and gone the extra mile to make a PR, I’d’ve been in the dark until I tried to commiserate (I always seem get the flu no matter what I do) with code and found my package erroring out.<\/p>\n

Enter: cdcfluview<\/code> 0.7.0.<\/p>\n

What’s Different?<\/h3>\n

Unfortunately, everything; which is one reason I’m writing this post.<\/p>\n

First, to have folks that are using current-gen cdcfluview<\/code> kick the tyres and let me know (via issues<\/a>) if you need any old API compatibility back. This isn’t anywhere near the most popular package on CRAN, but it does have users (even, I’m told, within<\/em> the CDC) and I want to make sure I do as little to disrupt them as possible. But, the current package API maps much more closely to the way the revamped portal works and presents data, so I’m hoping it’s a good net-new vs crushing blow to productivity.<\/p>\n

Speaking of maps, the package now has actual maps! A new cdc_basemap()<\/code> function returns the GeoJSON files that the CDC uses in their web views as sf<\/code> objects. And, there are tons of maps and multi-labeled features to tie data to:<\/p>\n\n\t\t