The REST Report

We were talking at work about Serverless: What’s the right tooling for developers building that kind of app? One of the businesspeople in the room said “Won’t developers need s special UI construction kit for Serverless apps?” The technical people all looked blank, because REST. Browser code doesn’t care (nor does a new-fangled React thingie, nor an iOS/Android app) what’s hiding behind that HTTP POST. REST is more or less totally dominant among app builders today. Is there any prospect of that changing?

What we talk about when we talk about REST · HTTP CRUD. Well, HTTPS actually these days, thank goodness. GET and POST, maybe a little PUT if you’re daring. Not much HATEOAS, to be honest. No deep thinking about idempotence, that I see anyhow.

All of which is perfectly OK, because it works. So your server doesn’t need to know whether it’s talking to a groovy TheNewHotness.js Single-Page App or a C++ Unity-engine First-Person Shooter running on a phone. And your SPA or FPS client doesn’t need to know whether it’s talking to a baroque Java EE monolith or a posse of funky micro-services. It’s only the most successful large-scale integration architectural style in the history of architectures.

[I may be pardoned a bit of glowiness about this, having spent a decade or so shouting that objects-on-the-wire (CORBA/DCOM/etc) were a bad idea, then another decade saying the same about SOAP, WSDL, and friends.]

Is REST running out of gas? · I don’t think so, but the app areas where you see non-RESTful deployments are interesting. Now, I’m talking mainstream business apps, so the use of UDP by the real-time bits of games is a big deal, but nobody’s expecting to see unsequenced datagrams replacing conventional web-site networking.

But what is interesting is streaming. I’m not talking about video streaming; that’s done with HTTP, anyhow. I mean, for example, Slack’s Real Time Messaging API; I bet a lot of people reading this are in a few Slack channels, and at the moment, that’s being done with WebSockets.

Which astonished me when I found out. It’s like this: Connections across the Internet, particularly when one end is a mobile device, are flaky, evanescent things. They all have one thing in common: Sooner or later, they break. Look at that Slack documentation I linked to above; it covers how to deal with disconnections. That’s sort of a pain for client authors, but apparently not too awful judging by Slack’s success. Still, a Google search for slack disconnect is amusing.

What I can’t figure out, though, is how they manage the server-side; maybe the technology has advanced, but I wouldn’t have the vaguest idea how to configure a fleet to terminate a few hundred thousand WebSocket connections. A hundred thousand HTTP transactions/second? No problemo, these days. But persistent connections? Cool stuff; Let’s see if it catches on.

I wondered aloud about this and Peter Cooper pointed me at The Road to 2 Million Websocket Connections in Phoenix, which has impressive numbers. Mind you, they cheated — they used Erlang.

Streaming for volume · There’s one scenario where I’ve become convinced that HTTP is stupid and wasteful. That’s where you have a small number of parties (like, for example, two) exchanging a huge number of messages. At some point, streaming has to win, right? Well yeah, but gosh, HTTP is still hard to let go of. There’s so much machinery there for it: authentication and encryption and routing and benchmarking and tracing and caching, so much a part of the ecosystem that you mostly don’t have to think about it.

Anyhow, seems pretty likely that the next little bit of the future will stay REST-centric. One of the nice things about that is you can think about changing out your server-side architectures, like for example going serverless, without breaking the world.

---

---

Contributions