

Why HTTP? - TimothyFitz
http://timothyfitz.wordpress.com/2009/02/12/why-http/

======
axod
OTOH, there are several things HTTP does ridiculously badly. It all depends on
what you're building. Evaluate the case, and sure, if you need a more specific
protocol, design one yourself. It's simple to layer on encryption, compression
if you need those.

Also the argument slightly reeks of the same "Everything knows how to deal
with it!" that caused some people to use XML for _everything_ regardless of
how well it fit the job.

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

~~~
axod
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?

~~~
potatolicious
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?"

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

~~~
potatolicious
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](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.

------
jacquesm
rsync uses it's own protocol (when run as a daemon), so does ssh and a whole
slew of others the common element is that http can not provide these
applications with the functionality that they seek.

I think that the golden rule should be something like:

If you can't do it on http you're free to roll your own but if you can do it
over http then you really should.

~~~
whacked_new
> 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?

~~~
jacquesm
can:

\- without getting really tortuous, but a little bit rethinking your problem
should be fine \- without sacrificing a large amount of speed or functionality
\- without compromising your design goals

~~~
whacked_new
Safe to say then, that it's a case by case and so, not so much a rule of
thumb?

------
CalmQuiet
OK, so I'm a noob about protocols. Can someone help me read between the lines?
Does TF's defense/advocacy for HTTP reflect a "threat" to its universality? In
any case, what protocols _are_ developing as alternatives (besides the
obvious: FTP, XMPP) - and for what purposes that HTTP cannot serve well?

~~~
moe
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.

~~~
iamwil
UDP and TCP aren't comparable to HTTP. HTTP is an application layer protocol,
which rides on top of UDP and TCP, which are transport layer protocols.

Be careful when you get carried away.

~~~
Gonsalu
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.4> "HTTP only
presumes a reliable transport; any protocol that provides such guarantees can
be used"

UDP does not guarantee packet delivery, thus HTTP cannot ride on top of UDP.

~~~
abstractbill
Actually it can, and does: <http://en.wikipedia.org/wiki/HTTPU>

~~~
Gonsalu
HTTPU is not HTTP. That's why it has a different name...

------
ankhmoop
I recently implemented an event logging server, intended to process a massive,
concurrent number of event messages from a large clusters of systems.

We choose to implement a CPU efficient binary protocol, automatic client-side
queuing of outbound messages if a server failed, and automatic -client-side-
fail-over to the next available server.

The initial implementation, with no time spent on profiling/optimization, was
able to receive and process 25,000 event messages per second from a single
client, and scale up clients/cores relatively linearly.

I can't even begin to fathom solving this problem with HTTP, or why the
'features' of HTTP listed (proxies, load balancers, web browsers, 'extensive
hardware', etc) would be an improvement over the relatively simple and highly
scalable single-tier implementation we created.

Clearly, HTTP works well for some things, but "just use HTTP, your life will
be simpler" is a naive axiom.

------
jff
Just do everything over 9p

