REST API Notes - 2018 and Beyond
Back at it!
I hope everyone was able to take some time at the end of 2017 to rest, relax, and recharge. While on break, I got to tinker with some Raspberry Pi projects, watch some Long Now videos, and build some Lego. I also reviewed the web API year that was. I don't have a formal methodology for graphing trajectories or gleaning insights. But, when given enough content, patterns begin to emerge. One thing, in particular, will be interesting to watch in 2018.
PEAK MICROSERVICES
Microservices have been the caffeine sustaining API conference and meetups for several years. Other waves, like like API-first, hypermedia, IOT, bots, webhooks, etc., have waxed and waned. All the while, microservices has remained a consistent topic.
Microservices can be a boon, for many of the reasons I've covered in the past (1, 2, 3, etc. ad nauseum). But microservices also increase complexity. If unprepared, an organization that mandates the creation of microservices as an act of cargo cultism, rather than something derived from need, will be disappointed.
"If you can't build a monolith, what makes you think microservices are the answer?" - Simon Brown, author of Software Architecture for Developers
In 2017, the stories told about microservices began to change in tone. It ranged from "practical approaches" (great piece by Diogo Lucas) to "don't go there (Nicolo Pignatelli), there be dragons (Dave Kerr)". As organizations mature their microservice efforts they are discovering that they weren't the silver bullet they originally hoped for. Even Sam Newman, author of the excellent O'Reilly book, Building Microservices, has urged people to pump the brakes, citing not only complexity but security concerns.
"OH: “we’re trying to draw a diagram illustrating a microservices solution to the architecture kata, but the diagram is getting complicated”. <— yes, that’s because the solution is complicated ... the diagram reflects reality!" - Simon Brown, author of Software Architecture for Developers, Twitter
The Gartner hype cycle is a useful visualization for how technology epochs progress. Something starts in obscurity, often as a label that aggregates detail of a useful approach into a useful shorthand. The popularity rises, as the framework, technique, tool, and/or technology's promise is popularized. Things crescendo as, seemingly, every vendor launches their own take, promising to cure-alls. What follows is a plummet, as those promises go unfulfilled, projects stall, and new options emerge. This, famously, continues to decline until we're in the 'trough of disillusionment'. It is at this point that the dilettantes move on. Meanwhile, that percentage vexed by the original problem carry on.
This year is when microservices slide down from their peak of inflated expectations. When I tweeted as much, Mark O'Neill, an API regular who now works at Gartner, agreed:
"Good call. Microservices were in the Peak of Inflated Expectations on the 2017 Application Architecture Hype Cycle in a point on the curve where failures typically start to be publicized and negative press begins. And thus begins the slide into the trough." - Mark O'Neill, Gartner Analyst, Twitter
That doesn't mean that microservices are any less useful. Or that development shops with projects in flight should jump ship and hop on the next bandwagon. But it does mean there will be an increasing amount of negative, even derisive, sentiment in the space.
"2020 prediction: Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications." - Kelsey Hightower, Google, joking on Twitter
OTHER PATTERNS
For every item, like microservices, that falls from the peak of inflated expectations there are exciting developments worth monitoring. In December I spent some time discussing service meshes. That, along with 'reactive microservices', will dominate even more conversation in the coming year. One could argue that both are nuanced wrinkles on microservices, and one would be right; splintering and forking of useful concepts happens during the descent.
PubSubHubbub is now a W3C Recommendation, standardizing the way to request a notification when a web page changes. If we think of the web not of pages, but of resources, there's suddenly an exciting (and standard!) push counterpart to REST APIs pull model.
Phil "His Milkshake Brings all the Trolls to the Yard" Sturgeon just published standards.rest. It is a site dedicated to tracking all the interesting standards developments including Irakli Nadareishvili's Health Check Response format. It joins Pedro Felix's HTTP API Specs as documenting substantive impact for API developers.
OpenAPI became the one Request-Response-API-description to rule them all. Then AsynchAPI came along and reminded everyone that APIs can be about more than request/response. The discussions will revert from "Which description specification do I use?" back to "Do I use a description specification?". For those that haven't built lifecycle automation pipelines around their artifacts, and for whom OpenAPI is just a documentation exercise, the answer is less obvious than one would think. Phil "That Guy Again" Sturgeon and Matthew Trask have launched a new site, OpenAPI.Tools.
2017 saw a number of API company acquisitions. I don't have enough understanding of the landscape to definitively say if this was a trend. However, looking back, I had to introduce the 'milestones' recap given the number of common-to-me companies getting bought up.
THE REST
"Where's GraphQL? gRPC/Protobuffs!? Loopback? Any of the various API Management tools and gateways? JSON Schema? JSON Hyper-Schema? JSON Mega-Deluxe-Platinum-Schema?"
One thing I've been interested in, as of late, is understanding the difference between fads and foundational drivers of growth. Why do something things barely last a year, while others have a timescale of decades? There are some things, like how the way the web works that was captured by Roy Fielding, that have become part of API terrafirma. Is it possible to get off the hype treadmill without missing the next essential change? Are we destined to chase every buzzword that makes it to a conference stage?
In my holiday reading, I came across Steward Brand's Pace Layer Theory. It gave me some tantalizing insight into why some things are slow to change, why others seem hell-bent on disruption every 20 minutes (have you heard about this new Javascript Library?), and how we might be able to achieve a balance between stability and innovation.
But this is getting long. Let's chat again next week.
Matthew