It has been a while…

As they say in Japanese, “お久しぶり” “oh-hisasshi-burri”. It has been a while. I took a short break from blogging some time around the birth of my second child, and also around the time that I was working on SOA with REST. A lot has changed since that time, but a lot has stayed the same. My youngest is now a teenager and I have moved from working on railways and SCADA systems to working with credit cards and such things.

Back in those days I was blogging with Blosxom. This time around I thought I would give Hugo a spin. I have long since lost the sources over various hard drive rebuilds, but was able to salvage content dating back to 2011 fairly well I think with some basic conversions. I wonder if anything I said back then makes any sense today.

I’d like to say that the world of REST and APIs has moved on in this time, and in some ways it has. There are many smart people out there doing good work. The RFCs for HTTP have all been rewritten by the HTTPbis group, which then advanced to HTTP/2. Worryingly perhaps, while HTTP/2 is still less than universal we also have a HTTP/3 on the way. This will unify HTTP with QUIC and will no doubt make things better once the dust has settled, much in the same was as USB-C will have been better once the dust settles on USB 4 and all that goes with it. Importantly, there is now little to complain about with HTTP as a protocol for all but the most miserly of applications.

The tension between synchronous and asynchronous architectures has heated up a little I think. A fair whack of the conversation a decade ago between REST architecture and the world of ESBs has swung, as pendulums do, with the popularity of systems like Kafka for managing messaging at scale. Using a distributed database in this way as a stateful channel between applications in appealing in many ways. Many of the same tradeoffs are evident if we dig into questions like how we solve CAP but pairing with Event Sourcing gives us a clear win in many if not most applications.

Describing HTTP APIs has gotten simpler and become more standardised with OpenAPI. Sometimes I feel like I am advocating a return to CORBA when I talk going API-first and generating message processing logic off a common specification, but it certainly does the job and I think most of us have come to terms with the idea that API governance even as the author of a pretty simple API tends to demand this kind of approach. Leaning back towards event-based systems I feel like there is still a gap here that is not filled in a fully standardised and accepted way as yet.

To give you a sense as to how long ago I wrote my last blog entry, I think I was still posting examples of XML message content just a few entries ago. XML collapsed pretty soon afterwards I think, from the weight of its standardisation processes. RDF never really got off the ground, and I think this was predictable in a sense. There is always a tension in knowledge and services systems between global vocabulary and local jargon as fairly neatly summed up in parts of DDD.

Security concerns around HTTP have evolved. Last time I posted I did so as a plain HTTP site. The thinking back then was that TLS (or SSL is it would have been!) is so integral to our lives that we might want to reserve it for cases where security was genuinely required. The new system where HTTPS has become ubiquitous has been good to a point. The need for VPNs has been obviated somewhat, and network administrators have little access the private goings on of individuals on their networks. But this was never purely a technical problem in the first place, and now we see the ever evolving ecosystem of mechanisms to reintroduce the feature of ubiquitous monitoring that has been lost in this transition. On the plus side, the user must generally now opt-in to invasive monitoring and that is a good thing. On the minus side we now scramble for ways to protect the privacy and integrity of messages within TLS pipes using various message-level encryption approaches. We know these messages are likely to be inspected by the owner of the network our user operates from, and if we are operating a service we likely have to be thinking with great clarity about whether our DDOS protection provider is going to crack open that pipe and have a look as well. But it’s all good. We’ll only use message-level encryption for really important stuff going forwards, so there will be no incentive for anyone on the network to demand the keys and take a look inside. Right? Ultimately we need to keep driving the system towards visibility of who has access to the data and hope sanity prevails in the arms race between genuine parties to an interaction and the powers that be or other parties that facilitate the interaction in some way while keeping anyone we don’t have clear visibility of out of it.

Well, I could go on but I think it is about time to pause for now. Hopefully all of you are well and doing well. I revived this blog partly to post a book review which will be coming in the next few days or so, but I think I might duck downstairs and pen another missive from time to time. Let me know of any issues with the new publishing platform or anything else you’d like to get in touch to say.

Benjamin.