Ok, so I think I identify as an elder millennial – not only because of my rather sparkly salt & pepper beard and rather well-placed b*tch strip, but because I do fall on the early end of the generational group and yes, I’ve reached that ripe old round figure of 40.

When I entered into my “digital” career, the term “hackathon” had just been mainstreamed, Twitter had just raised their series… something, and everyone was on the hype train about REST vs. SOAP in API land.

In this age of yore, the term “Mashup” was thrown around everywhere, the programmable web was suddenly a thing, and all of my co-workers and palls were grabbing APIs left and right and mashing them into bizarre concoctions. I clearly remember at one point working on a paid-for-project where we needed to “mash up” the newly-minted Google Maps API with a map of toilets in the general London Area, and then figure out a way to measure the strength of an elderly persons urine stream in order to help create awareness for prostate cancer… yeah, those were some weird times.

Regardless – I think what I’m getting at here is that the early hackathon and mashup days were the real beginning of the wide adoption and normalisation of APIs in the wider non-technical scene, and more importantly, set the foundations for a kind of democratisation of information, while setting the scene for a utopia where all information would be at our fingertips, and we would all just hack together pipes of data to get the results we wanted (remember Yahoo Pipes – such an awesome project).

Don’t get me wrong, hackathons are still a real thing, though they have lost a bit of their grass-roots charm, and now live well and truly in the corporate “hi fellow kids” world of siphoning talent and enthusiasm out of young bright-eyed graduates.

I also don’t think that “mashups” are gone either, the term just isn’t relevant anymore, the concept of combining data from multiple sources to create value is now a widely accepted norm in the modern consciousness, we can thank connected smartphones and well-designed apps for that.

The move towards REST was a big driver behind these changes – many developers poo-poo REST in principle because it works on conventions, is not designed for every use case, can’t really perform RPC, and suffers from a blight of not-invented-here-ism where every API has it’s own bizarre quirks to make standardised clients impossible without SDKs (I know we have OAS now, but it isn’t a silver bullet).

However, the move to REST came with one killer feature: you could do it in the browser, no client, no code, just type an address into your browser. If you needed more complexity, you could use pre-packaged tooling like grep and curl to quickly experiment and hack together something that would do something with a bash script.

That availability, that ubiquity of access makes REST the clear frontrunner for anyone who wants to publish an API.

This is probably all sounding pretty old hat, the thing is – over the past ten years, we’ve got newer additions, JSONRPC, XMLRPC, Thrift, gRPC, and now GraphQL as contenders for building better faster and interconnected systems.

Out of these, I think the only one that gets me in any way excited is GraphQL (no bias there folks!), but it, like any other modern API standard suffers form the difficulty of getting productive without resorting to code and SDKs. Yes, the query language is standardised, and yes, an API owner could enable the sandbox – but it still suffers from that lack of instant gratification of being productive right there and then.

And I’m not alone in thinking this – many of our clients, when looking at Tyk’s Universal Data Graph to transform REST and SOAP to GraphQL or to get started quickly with GraphQL in their legacy systems, will think the concept is awesome.

However in the end – they still choose to make REST their public interface, even if they are driven by a GraphQL API under the hood.

It’s just like the REST-Mullet of yesteryear – where your legacy APIs have a RESTFul shim in front of them that translates requests so that you can be one of the cool kids.

Just it’s worse… it’s: REST -> GraphQL -> REST or worse SOAP -> REST -> GraphQL -> REST. Where the only folks using the GraphQL interface are internal developers to boost productivity. But the public or their customers gets siloed into REST. Why? Because REST is idempotent, easy to understand and easier to secure.

APIs are getting weird, man.

Ok – memberberries rant over…

So, are APIs – in the form as we have them now – still giving us the potential for a “force for change” and “making lives better”, than they were when all the hype started around mashups? Or are they now so normalised and had their value captured in the “API Economy” that the wild-west nature of building interesting things is now hidden behind a paywall?