If you program the web in Clojure, you probably use Ring. Even if you don’t, your server is likely Ring compatible.

Ring has a small SPEC. It’s centered around defining the keys one can expect in the request and response maps. And the exact names for keywords are easy to forget.

I don’t want to forget. I use Ring often enough that I want a quick reference. A while ago, I printed out a quick summary of the keys for the request and response maps and hung it on the wall behind my monitor. I refer to it frequently.

If you program the web in Clojure, you might appreciate this printout. If you’re learning, it could be an invaluable reference.

One change in Ring 1.3 is very significant: the specification is shorter. It’s simpler. Three keys were deprecated in the Ring request map (:content-type, :content-length, and :character-encoding). These keys were unnecessary because their values were in the headers, which are also in the Ring request. Equivalent utility functions have been added for pulling the data out of the headers.

Why is this important? While many libraries get more complex and overburdened, it is refreshing to see a library going in the correct direction of shedding complexity. It does not significantly impact application development. Nor does it reduce the already low barrier to entry. Still, I welcome this kind of change.

Ring is the central specification that ties most of the Clojure web ecosystem together.The spec should be minimal. And a mark of good software is that it models the problem very closely without unnecessary abstraction. Ring merely defines a common format (using Clojure data structures) that mirrors the text-based HTTP message format. That’s why Ring has worked so well thus far and why it is appreciated in Clojure.