Why HTTP?

The main point seemed to be that you wouldn't need to layer much, if anything, onto HTTP. That is not necessarily that much of an advantage, depending on your environment, but should be worth considering.

God I hated those arguments so much. I especially hated being told I should be using xml "because the parser is already written" as if writing a parser was the difficult part of... well anything really ;-)

HTTP isn't perfect, and there are plenty of times when a custom protocol makes sense. However, I think the author is arguing against the "everything needs its own custom protocol" mindset which is all to prevalent in the corporate world. In my work for USPS, I've encountered numerous custom protocols, most of which are far inferior to vanilla HTTP and which cause endless headaches due to poor documentation, debuggability, extensibility, bugginess, etc.

So I agree with the author and my own approach to protocols is to start off with the assumption that I'm using HTTP and only use something else if there's a good reason why HTTP isn't appropriate (performance being the most common dealbreaker).

On the other hand, you're giving up extremely well designed integration with almost every language and runtime on the planet. Why use your own custom protocol, when you could use HTTP? The argument isn't that HTTP is always better, but rather that it should be the default choice.

Interestingly, rsync can be used via an HTTP proxy, so presumably the protocol gets divided into HTTP requests. Doesn't seem too crazy really: HTTP supports partial downloads and uploads, and the rolling hashes can be easily be encoded in HTTP requests, too.

> if you can do it over http then you really should

There seems to be some wisdom here that I am not extracting successfully. It seems HTTP "can" in most cases. But where it can, do you really want to use it? Technically you could also write a db engine that reads over HTTP, but this must be a terrible idea; what would be the argument here that counters the rule of thumb?

Well, it seems the author drank a bit too much of the webservices kool-aid. HTTP is just one protocol amongst many. It was never meant to be "universal". The only reason why it's being abused for even the most unsuitable tasks nowadays is because when all you have is a hammer then everything starts to look like a thumb...

There are many purposes where HTTP is not suitable at all. Realtime audio/video comes to mind - UDP is commonly used here because even the TCP latency is too much. Anything where you need a persistent, bi-directional connection is not a good match either. Anything where you need to push from server to client. In short: Anything that doesn't fit into the request/response paradigm.

In fact, many consider HTTP in its current incarnation to not even be suitable for the interactivity that we expect of modern webapps.

But ofcourse that doesn't stop the truly enlightened. Hence we got abominations like "Comet", a persistent stream-socket emulated on top of an inherently request/response-based protocol. Or RSS, which is nothing more than Usenet done really, really wrong - all lessons unlearned.

Sorry, got a bit carried away. But you get the idea I guess.

FTP is actually a lot older than HTTP and therefore wasn't developed as an alternative. Traditional, multi-socket FTP actually has massive disadvantages in today's firewalled, NATed internet. HTTP is more useful than FTP or most other protocols for transferring individual files these days. I've never worked with WebDAV, but it seems like it would be a preferable alternative almost anywhere you might use FTP.

As an example where HTTP doesn't work so well, is pushing information as opposed to servicing requests. COMET is a hack and requires you to be very careful with clients. (e.g. the 2 connection limit in older browsers) You'd only really want to use it where there's no alternative, like in a browser.

Basically, HTTP is great for servicing individual requests. It can do kind of do persistent connections, but they're more an optimisation than part of the design and therefore optional for the client even if the server suggests them.

If your use case falls outside of the basic request/response premise, you can maybe use it for prototyping for a while, but you should probably switch to something more suitable to your setup after that unless you need to use HTTP for reasons outside of your control.

Well, depends on your problem. If you have a sensor network that needs to transfer information, but needs to do it in an energy-conscious fashion, HTTP might not be the best choice.

Sensor networks are a bunch of sensors that collect info, then network themselves to transfer what they know, usually to a mothership base station of some sort. Because it's a pain in the ass go out in the field and replace the batteries on these sensors, you have to make their transmissions energy-efficient. There is nothing in the HTTP protocol that takes energy consumption into account. Nor should it. It's not an application layer problem. However, the only reason I mention it, is that I've seen people start mixing the protocol layers together in a single protocol to achieve the energy consumption characteristics they want, which included the application layer.

So hence, that's one instance where HTTP isn't a first choice. As long as you know what HTTP is for, and don't use it blindly, you'll find that it probably suits your needs.