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).

Oh, you mean like SOAP or XML-RPC? Yes, I would prefer using HTTP as a protocol over using those any day.

Sarcasm aside, I don't see exactly what HTTP buys you over establishing a TCP connection to the server and talking to it directly. Points one and two, check. If your favorite language can talk HTTP, it can talk over TCP.

Besides, in a URL like http://foo/bar?v1=x&v2=y&v3=z is in itself a type of protocol, namely the name/value pairs. Sure, I know HTTP and can debug problems at THAT level, but what about at the higher level? There's still a protocol (oh, I forgot that v4 is mandatory when calling bar, but optional when calling baz).

You make it sound, as the author does, like HTTP is applicable to anything. It's not.

It's a very specific request/response protocol, which suits some specific purposes.

>> "start off with the assumption that I'm using HTTP"

That's ridiculous. So if you're writing a multiplayer real-time game, you'd assume you're going to use HTTP?

Read the rest of his post - he mentions specifically that performance issues would probably be the number 1 reason to not use HTTP. Bear in mind also that most applications are low-bandwidth, latency-insensitive, and do not need to make optimal use of available resources. This makes HTTP very quick to implement, nearly universal in compatibility, and fairly foolproof.

I think he was complaining more along the lines of "why are we running a custom protocol when we're just passing along a bunch of strings?"

Why are we using HTTP (and bundling in a web server) when all we're doing is just passing along a bunch of strings?

Because the tools are there to support this. Let's just say I want to be able to query the current weather at a longitude/latitude, and I want to make sure this service is accessible not only to my client application, but also any other apps that want to integrate this feature.

I can:

- Write my own protocol with very low overhead, just a simple TCP handshake, the client sends me a little string with its location, and I send back the weather. Simple, really fast, has low network and processing overhead. But then you find that this is almost impossible for someone to integrate into their webapp, or even a native app, without opening sockets and doing a stupid amount of work just to set up that connection. I can also write my server code in C++, which gets me some hellishly fast performance.

or

- I can implement it in PHP, and accessible via a URL like http://www.mysite.com/weather.php?lat=X&long=Y and be done with it. Total coding time? Almost zero. There is no need to set up or tear down connections, and no worry about things like encodings, endianness, or anything of that sort that you'd have to worry about with a raw TCP connection. These tools are also proven, and relatively bug free, which one can't confidently say about anything they re-implement themselves at a low level. Hell, a simple shell script can curl my URL and get the weather back, just like that.

There are gains to be had for doing everything yourself, but for the majority of webapps the tradeoff in reliability and ease of use/development simply isn't worth it. The existence of talent, tools, and community knowledge is often worth the lower performance and sometimes unnecessary overhead.

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.

This is a ridiculous conversation though. The default choice for what?

What are we even contemplating building here? HTTP is clearly not a sane choice for everything, and most likely not a sane choice for the majority of things people build.

This argument is like saying "If you're going to write any software, you should assume you'll write it in Java, unless you have a good reason not to". (Which some people were probably chanting in 1998).

The author seems to be complaining that MySQL doesn't use HTTP.

To be fair, I've at least taken the approach of starting with HTTP for many projects (knowing I'll probably ditch it at some point) - the author does have a point about it being very easy to debug using things like wget and your web browser.

Sure, but if we were working on something like skype, or a multiplayer gaming network, or an instant messaging system, HTTP wouldn't be an obvious choice.

Maybe I missed the part in the article where it said "In the world of websites/webapps... etc" :)

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 ;-)

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.