REST API Notes for 2018-04-11
Do you remember where you were when Facebook launched its Platform? The announcement, in May of 2007, may lack the gravitas of a moon landing or presidential assassination. But for developers with a keen interest in 'Web 2.0', or the social web, it was a watershed moment.
At the time, I owned my own web consulting firm. I also organized and attended a number of developer meetups. The idea of building applications on the Facebook 'social graph' only added to the gold rush fever in the air. I distinctly remember when an entrepreneur, prone to hyperbole, declared that building applications for the graph was "the next Internet!".
In a gold-rush, people do make money. Some people. While I never knew anybody that had Zynga-level success, one perl programmer at our events re-invented himself as the "social geek". He flipped a few of his early land-grabs for modest sums while blogging about his prowess. And the entrepreneur that induced eye-rolls? He prepared to do battle with Google.
Yeah. In hindsight, that guy was... something.
Fast-forward about ten years. Last I heard, the social geek has been having a rough go of it, posting ever-more derisive click bait in a bid for attention. The entrepreneur is now doing some kind of life-coach, multi-level-marketing scheme. And Facebook, after admitting that the Cambridge Analytica data collection may have effected nearly twice as many people as originally thought, upended its APIs.
Instagram, owned by Facebook, had planned deprecation for numerous items this July. However, in the most recent changelog, the deprecation was immediate. Facebook, further, restricted its APIs.
There's a difference between building a business and building a platform. I, previously, mentioned my concerns over knee-jerk regulation in light of a disaffected mob looking for its pound of flesh. I'm also concerned about the implications on the boardrooms, where 'platform' ping-pongs from silver bullet to boogeyman. Either extreme isn't good.
There are three successful open API models between providers and third parties:
- Software-as-a-service (SaaS), where the software is already built. Think the original incarnation of Salesforce, where it was an entire customer relationship management (or CRM) system that could be integrated with. You integrate with a SaaS.
- Platform-as-a-service (PaaS), where all of the pieces to build software are readily accessible but the integrator brings their own logic. Twilio or Sendgrid, in my mental model, are here. You program for* a PaaS.
- Infrastructure-as-a-service (IaaS), where virtual servers and related raw-compute services are sold. AWS, Azure, etc are here. You deploy to an IaaS.
With these definitions, the closure of ESPN's open API program makes more sense - where does a read-only stream of sporting events fit in those business cases? Spoilers: it doesn't. So, where does a Facebook (and associated properties) open API program sit? Have the benefits of an open API program changed over time? Does supporting APIs still warrant the risk of being called to testify on Capitol Hill?
All fascinating questions that, I'm sure, are being hotly debated this week.
TWITTER "STREAM SERVICES" SHUTDOWN (AND SUBSEQUENT BACKTRACK)
Last week Twitter announced that it would be ended its "streaming service", to be replaced with an upcoming "Account Activity" API. The effect would result in a number of popular third party Twitter clients - Talon, Tweetbot, Tweetings, Twitterrific - no longer having the ability to do push notifications and auto refreshes. The outcry from both users and apps dependent on the service was immediate. Twitter, nearly as fast, announced deprecation of the streaming service would be postponed until "at least 90 days after the Account Activity API becomes generally available".
ORACLE-GOOGLE FOLLOW UP
But wait! The fun doesn't stop there. Follow last week, we have a copyright- notice-in-the-API-header sighting.
I know I'm going to shock quite a few folks when I say that I'm no lawyer. For those keeping track at home:
- In 2012, a Washington, DC judge ruled that an API couldn't be copyrighted
- In May, 2014, a federal judge reversed the ruling, saying that APIs could be copyrighted but remanded the case back to a district court to determine of Google's API constituted 'fair use' of the copyrighted work
- Two years later, a jury determined that Google's use was an example of fair use
- Now, in 2018, an appeals court has determined that Google, in fact, is not covered by fair use
Google can appeal to the supreme court. However, it would appear that whether APIs are "copyrightable" is not up for debate - that appears to have been settled in 2014 (although that still doesn't seem right). What is being fought over is the fair use question. If that's the case, what the community might need is a standardized header for copyright. Got an approach? I'd love to hear it.
MILESTONES
Just a quick one this week: Talend joins the Open API Initiative. Long time readers will remember that Talend was the company that acquired Restlet at the end of last year.
WRAPPING UP
If you're looking for an upcoming API conference to attend I'd encourage you to check out webapi.events. It list in-person conferences and meetups around the world. And if you know of an event that isn't list shoot me a quick note - either respond to this note directly or send me an email at 'hello@matthewreinbold.com'.
Til next time,
Matthew