Guest blog: Beyond REST - the future of web APIs
Colour Splash Be-IT Blog

Guest blog: Beyond REST - the future of web APIs

Guest blog: Beyond REST - the future of web APIs

Posted on 26th October 2018

LinkedIn ShareShare

REST graphic

This is just a little shameless promotion of the forthcoming BJSS RESTful API talk in Glasgow, which has a handful of places available for those who are interested you can find the details here!

I'm going to follow these talks with a much more in-depth article on the topic, but here's a little precis to whet your appetites.

The Future of APIs - It's Upon Us!

It’s sometimes strange how the IT world evolves, as APIs have long been unloved in technology circles; they’re not “cool” like the Blockchain or AI and they weren’t something that in the past would have been considered a badge of honour on your CV. APIs were something you tacked onto the end of your project because one awkward client asked for them, not because they were an up-front need. But times have changed, and as the migration to the cloud gathers momentum, the integration and federation of services becomes more important than ever, and they’ve suddenly become incredibly relevant.

This recent increase in relevance has come from several angles, meaning the drivers for moving to APIs are complex and sometimes a legal requirement. The Open Banking and Healthcare movements are leading the way on not only having well-designed APIs but by going one step further by making them "front and centre" of software design and development, rather than just being an afterthought. Also, Software Defined Networks (SDNs) are designed to be controlled via APIs, so it’s not just your software itself that’s API driven nowadays, it can be the infrastructure it sits on too!

The bottom line is, that if you’re not harnessing the power of APIs nowadays, you’re behind the curve. Further to that, you can’t just “do” APIs anymore, they must be well-designed APIs that exist in a sustainable ecosystem, otherwise people will use alternative offerings.

But this has meant that we’ve all had to do some rather sudden upskilling in this area, learning about how to design, consume, build and expose effective APIs, most of which nowadays are RESTful (SOAP API adoption has flatlined).

Where Have We Gone Wrong With REST?

This brings us to the current problem with RESTful API adoption as we’ve been left in a bit of an unstable situation. We had SOAP and it was largely disliked for its byzantine structure and methods, enforcing compatibility through rebuilding your interface via published WSDLs. REST seemed like a refreshing change, however it’s too simple as it’s just a pattern, it has none of the structure and rigour of SOAP, which is both a benefit and a danger. It comes with none of the authentication, authorisation, reliable messaging, versioning or concurrency control that are possible using the WS-Standards when implementing a SOAP API.

Now we’re reaping the rewards of changing tack en masse and API programmes are either failing or causing significant problems to both providers and consumers. There’s plenty of opinion out there on how to implement REST successfully, but it’s patchy and contradictory, due to the lack of standardisation and direction. There is no current holistic answer, which is actually a step backwards!

Let's Open the Debate on "What Can we do About it?"

In order to move the industry on, we have to ask a number of questions about where we are now. There’s much more to REST than just JSON over HTTP (a common misunderstanding of REST at a fundamental level), but some of the pertinent questions are:

  • Is REST the right idiom for us?
  • How could it be “fixed” if it is right for us, what would we add?
  • Which bits of REST as currently understood, do we retain?
  • What else is out there that’s usable?
  • How do we migrate or make things work in harmony?

But it's Not All About Technology

As a community, we have to recognise that 80% of the time, what we're trying to throw technology at is a human problem and API adoption is no different. It's worth considering the design, leadership and community implications of going "API First" in your design if you want to become a provider of modern, usable and (most importantly) sustainable APIs.

Throwing technology at the API aspects of your service without considering these aspects is doomed to mediocrity or worse, failure. But by being a little forward thinking and considering what the future of APIs looks like, you could deliver something quite special.

That's All for Now, Sorry to be a Tease!

In my upcoming talks I try to address the above by discussing REST, how and why it has “failed” (the implementers, not the pattern itself), how it can be extended and what alternatives are out there for current use.

I hope to see you there!

Jeff Watkins, Principal Architect, Tech Blogger, RESTful.


Posted in Guest Blog

.. Back to Blog

Be-IT Accreditations