Most merriest of Christmases, happiest of holidays, and/or grandest of new year well-wishes to you! I hope that you've been able to find time to relax and reflect during this past season. Today starts another busy, new day to a new year. In the world of RESTful APIs, that means new links to read and thoughts to share!

A YEAR IN REVIEW

Hypermedia APIs, the Internet of Things (IoT), and Microservice APIs remain popular conference topics. However, over the course of 2015, I saw less wild-eyed pontificating and more thoughtful, purposeful benefit elaboration. That maturity is great to see.

I also continued to see the closure (or reduction) of external API efforts. For every Pinterest that is starting a public API program we have a LinkedIn restriction-of-service story. While a few data points does not equal a trend. However, I hope we've passed the "build it and they will come" as-a-strategy phase. Externalized RESTful APIs are products. Therefore, they necessitate product management and business model support, no different than any other company offering.

In 2015 I geeked out over the ramifications of Amazon's API Gateway. The gateway has less to do with API Management and more to do with an entirely new programming model for APIs. Kin Lane, the API Evangelist, spent some time digging into the nitty-gritty details. "Paradigm shift" is a trite buzzword phrase. But a RESTful interface for serverless infrastructure is a different beast. I look forward to see how developers tame it.

Last year saw a tremendous amount of maturity in the API description space. There are alternatives - API Blueprint and RAML, for example - but Swagger seemed to emerge as a front-runner. Even developer tool stalwarts like Visual Studio got in a Swagger-strutting press release. In March API tools company Smart Bear assumed sponsorship of the Swagger API Open Source Project. In September, this was followed by Tony Tam, creator of the Swagger API specification, joining the company. The collaboration resulted in Swaggerhub, an exciting API-design-first tooling. By the end of the year, the Swagger 2.0 specification had become the seed for the Open API Initiative, an official Linux foundation project.

What does having a human and machine-readible documentation for an API mean? James Higginbotham has a great piece on Moving Beyond API Reference Documentation.

SO WHAT'S NEXT?

What's next? What should we be on the lookout for in 2016?

There certainly is no shortage of "sexy" topics that are capturing developer attention. The Amazon Echo, or "Smart Agents" in general, turned many heads. The Amazon Echo, and other voice systems like Cortana, Siri and Google Now, represent new interaction patterns. Embracing an API organizational model isn't just about powering native apps. Companies that have gone through the effort of exposing their core competencies through cohesive API interfaces are best posed to power these new interactions.

Daniel Jacobson, most recently of Netflix, has talked about orchestration, or "experience layers", for years. However, many dev shops are, only now, getting to the level of internal complexity where orchestration is becoming an issue. A native app powered by a single abstraction for a database is straightforward. Managing a complex ecosystem of microservices that, collectively, build a user experience is another thing entirely. Randy Shoup has a great InfoQ presentation from last year on "Building Service Architectures at Scale: Lessons from Google and eBay".

Unfortunately, in 2016, I believe we're going to see what Maciej Ceglowski calls "digital toxic behavior". These are situations where the data exposed through APIs is used for nefarious ends. In 2015, a proof-of-concept used the genetic information from 23andMe to block people based on race and gender. Keith Casey elaborated on the potential harm. I expect see at least one news story in the coming year where data exposed for one purpose is, troublingly, distorted for other ends.

Finally, more industries will wake and find, regardless of what they did yesterday, that they're in the software business. This is the natural manifestation that "software is eating the world". If you don't provide an API but what you publish is valuable, then people will get it without you knowing. There's already a handful of sites that turn websites into APIs - Kimono Labs, Import.io and ParseHub come to mind. Add to that any number of services that have evolved powerful screen scraping capabilitites. Companies have a choice: they can either create the safe, understood, and measurable interactions with services that want to access their data, or people will get the information anyway and they see no benefit. Developers have seen this. But, increasingly, the business side does too, as Mark Boyd points out.

WRAPPING UP

Thanks to all of you for reading this far, who have subscribed over the last year, and/or have commented. The RESTful API community remains vibrant because of the work you do each and every day. I can't wait to see what this year brings!

Until next time,

Matthew (@libel_vox)
http://voxpop.co