Let's Talk About REST

Remember the early 90’s and Salt-n-Pepa? No? Well, it’s about breaking taboos around talking about important topics. In a vaguely comparable way, we software engineers have a kind of taboo on talking about REST. Let’s break that. Figure: “Rest here” by oliverkendal is licensed under CC BY 2.0 See, most of you will know what REST means, right? And the majority of my readers will be able to tell me that it stands for REpresentational State Transfer.

Channel Capabilities

OK, so in the last post, I was getting into some channel capability flags, and how they impact handling of lost packets. The main conclusion for the purposes of that post was that we need some kind of sequence numbering in every packet, unless we just so happen to switch all reliability flags off. Saving bits is a noble goal to be sure, especially when you have WiFi induced low MTU on the path.

Handshakes

It seems as if I start every piece here with an apology for taking so long to continue writing. That’s the nature of my life right now, it seems. I’m sorry. So let’s dive right in. Last time, I was writing about how different channels interact with each other, and what that means about messaging in fairly abstract terms. I also wrote before how I’m not a big fan of negotiating protocol features, and prefer to instead iterate to a new and improved protocol faster.

Message in a Bottle

Since I took such a long break before my last post, I figured I should forge ahead and write them while I can. Previously, I outlined the packet envelope information we’re going to send over the wire. Today’s topic is the basic messaging framework, handshakes and some considerations on channel establishment. To recap, every packet belongs to a channel, and may contain one or more messages. In the absence of any other established channel, packets will belong to a default channel.