In my day job I see lots of CVs and most of them are, frankly, terrible. Some of them are probably OK for applying to companies you don’t want to work at, like banks or large consultancies, but if you want to work in a small startup-like company with really smart people then you need to rethink a lot of what you’ve got on there. Not that I’m necessarily including myself in the really smart category, but I’m doing my best to make sure everybody who works for me is; managing people is easy (or easier, at least) if they’re better than you!
I’ve spent quite a lot of time over the last few years thinking about, designing and building RESTful APIs. Far more time than I expected, given that they have a reputation for being very simple. They’re not. In fact, I’d go so far as to say that RESTful APIs are harder to design, harder to build, and (depending on your language of choice) harder to consume than just about any other style of web API.
Back in the early 1990s Java was conceived as an alternative to C++ which would be portable, garbage collected, and easier to learn, but still retaining a C-like syntax to make programmers feel more comfortable migrating to it. There are a variety of reasons why Java became so popular on launch, marketing not being the least of them, and now it’s one of the most popular languages in the world. Perhaps the most popular, depending on which statistics you believe.
This post is an attempt to provide an easier to follow version of the rules laid out in RFC 2616 §§ 13-14 around HTTP caching and the impact of various HTTP headers on them. Some detail has been simplified and/or omitted to cover only the subset of HTTP typically used by RESTful APIs, as it was research into the blinkbox Web API that led me to write this.