REST API Notes for 2018-07-26
Another week, another business trip. It not only has been a rainy July in Virginia, but there's been a steady drip-drip of API notes to check out. Let's dig in.
NOTES
API LOAD TESTING
The first "Day Camp for Developers" virtual conference recently concluded. Ian Littman, who spoke at the event, has shared his deck "Load Testing your APIs". I love how Ian takes a pragmatic approach to his advice; rather than advocating to 'test all the things', he carefully lays out the different types of testing and when each is appropriate.
API-DESIGN FIRST VS AGILE?
Watching from afar, the agile community is having something of a "dark night of the soul" moment. It is caused, in part, by the many misconceptions and half-truths that harried and ill-informed, yet well-meaning, individuals perpetuate in its name.
These folks are often the type that look at 'API-design-first' efforts and dismiss it as 'too waterfall'. James Higginbotham, who I work with on a regular basis, has a great piece on "API Design First in an Agile World". In it he revisits the agile manifesto, establishes a firm theoretical foundation, and then reconciles those core tenants with API-design first thinking. Highly recommended.
APIS AND THE NEED FOR PLAIN LANGUAGE
Kin Lane, the API Evangelist, recently posted a moving request for developers to use plan language in describing their APIs. I couldn't agree more. Just because I can order a meal in a restaurant or read a stop sign - the everyday, ordinary actions where the language processing centers of the brain are engaged - doesn't mean I am an effective communicator. To communicate well is a skill. Speaking in internal acronyms and localized jargon means inserting a comprehension barrier between you and the other parties. Putting ephemeral names - like teams or projects - into the paths is equally frustrating.
Involving a good product manager - someone who is skilled at evaluating user needs, and matching intent to their understanding - can help. Finding those product managers that can 'speak' API is challenging, but it can be done.
MILESTONES
- Venmo had an security leak due to poor API design. The result was, among other things, a bot that tweets photos of people who bought drugs with the service. I highlight this not to throw blame, but so the community can use this as learning opportunity.
- Whoop! Whoop! A new version of the sunset header has been published. I would love to see this kind of programmatic, standardized communication of changes become more popular.
- Spotted by Mark O'Neill, IBM is deprecating a number of its APIs on August 18th. Looking at the list, I don't see any shockers (in fact, I'm puzzled why some of these existed in the first place). The point, however, is not that some APIs are going away - that thing happens everyday. As Mark correctly points out: "It is tempting to think that you just register your API in a number of marketplaces and then immediately start making money. This is not the case."
- Finally, there's fascinating piece on the impacts of Google Maps API price increases. Much business strategy to break down here, but it furthers the caution that developers of commercial products need to exercise when building core functionality upon another company's infrastructure.
WRAPPING UP
Last night I did a Mission Impossible themed sprint to update webapi.events. The goal was to move webapi.events from the insecure http to https protocol for numerous reasons. The play-by-play is on Twitter). In the end, the design is bare-bones and Chrome hates the usage of Github cert with a custom domain name. #winning?
I'll have a full-write up, similar to what I did for my personal site, up shortly. In the meantime, if you have an upcoming, in-person Web API gathering that should be shared, let me know and I'll add it.
Also, if you'd like to show your support for this, and other, community efforts, check out my Patreon page.
Thank you for reading. Till next time, Matthew