REST API Notes for 2018/12/03
December is off to a busy start! I had a business trip last week and my go-bag for this week is at my feet as I type this. I'm leaving the country for a bit, so all the more reason to get this edition of the REST API notes out while I have a reliable wifi connection!
NOTES
MARK W. FOSTER ON CLIENT-DRIVEN APIS
What is a Client-Driven, or 'consumer-driven', contract? As the name implies, it is an API where the client is in the driver seat, modifying the payload as need be for their particular use case. If that sounds like GraphQL, you'd be right.
In this presentation, Mark Foster not only provides the rational argument why client-driven is viable; I also found his recap of distributed system history enjoyable as it was concise.
TIM BRAY ON "POST-REST"
Whenever a piece has a link-baity title, there's a pretty good chance I'll close the browser tab before reading further. And, as far as link-bait goes, "Post-REST" is up there. There's an implication that (1) there is a "right" architectural style, (2) REST is over and (3) the downsides listed for REST (latency, coupling, and short-life) don't have reasonable foils.
That said, there is some useful compare and contrast between GraphQL and gRPC approaches. These aren't the usual breathless, silver-bullet retellings, but rather, some shrewd observations on what situations they might be good for.
So if Tim is dumping on REST and pumping the brakes on GraphQL and gRPC, what is his future, Post-REST, architecture? Messaging and eventing, orchestration, and persistent connections. So. Yeah. I mean, that is a way. But it doesn't alleviate the slights thrown at REST. Coupling, in particular, can happen with any software architecture. Slack on the message design and boop!, you're suddenly tracking down subject matter experts (SMEs) to get things done.
It's an odd little piece. But, given the number of times it popped up in my circles the past few weeks, I think it is worth having a critical discussion over, even if the ultimate assertion raises my neck hairs.
MILESTONES
- There's a new Technology Radar from ThoughtWorks. In this edition, there's an interesting trend called in the "Lingering Enterprise Antipatterns" section: > "Many of our Hold entries decry an old wolf hiding in new sheep's clothing: enterprise service bus (ESB) behavior implemented on event-streaming platforms—Recreating ESB antipatterns with Kafka, Layered microservices architecture, Data-hungry packages, Overambitious API gateways, Low-code platforms and other noxious old practices. The fundamental problem, as always, is the balance between isolation and coupling: we isolate things to make them manageable from a technical perspective, but then we need to add coordination to make them useful for solving business problems, resulting in some form of coupling. Thus, these old patterns keep re-emerging. New architectures and tools provide appropriate ways to solve these problems, but that requires deliberate effort to understand how to use them appropriately and how to avoid falling back to reimplementing old patterns with shiny new technology." What a coincidence this followed the preceding piece!? [Narrator: It was not coincidence.]
- USPS had an API data breech, exposing information on 60 million users. The problem was related to an authentication vulnerability in the USPS's real time package tracking API. From the article, "the flaw let any logged-in usps.com user query the system for account details belonging to any other users, such as email address, username, user ID, account number, street address, phone number, authorized users, mailing campaign data and other information". Or, in other words, while the API validated that they user was who they said they were, it did not check to see if they had permission to request the information they were asking for. That's pretty bad.
- POSTMan has announced a beta for OpenAPI support. Being able to import an API via OpenAPI seemed like an obvious thing. Excited to see this come about.
- Palantir introduces Conjure, a toolchain for creating JSON APIs. I was about to dismiss it given the company's controversial business model. However, there's some interesting things in the announcement about consistency and embracing the limits of RESTful design.
- Sebastian Caceres, a talented web comic and astute observer of technology, published a funny comic on distributed monoliths. Check it out!
WRAPPING UP
Interested in attending an in-person API event? Webapi.events has you covered. It lists ongoing conferences and meetups around the world related to APIs. And do you see something missing from the list? Shoot an email at hello@matthewreinbold.com and let's talk.
I'll end, per usual, with a thank you to my Patreon sponsors. They help keep the cold beverages alongside on the odd hours it takes pulling these things together.
Till next time, Matthew