Why HTTP?
Why HTTP?
The world doesn’t need another arbitrary binary protocol. Just use HTTP. Your life will be simpler. Originally this came up when scaling a gaggle of MySQL machines. I would have killed for a reliable proxy. It’s with this in mind that I’ve come up with my list of things that HTTP has that an arbitrary protocol will have to rebuild. Anytime you choose to use a service based on a non-HTTP protocol, look over this list and think carefully about what you’re giving up.
1. Servers in any language.
2. Clients in any language.
These two are obvious. Moving right along.
3. Proxies
There are rock solid drop-in software solutions for proxying traffic from one machine to another. These proxies can do all types of request or response rewriting.
4. Load balancers
Need to scale past one machine? Need higher reliability? Drop a load balancer in front of multiple machines and you have a transparent barrier around the complexity of scaling up a service.
5. Debugging tools
There are no problems that have not yet been encountered. In fact, there are probably tools for diagnosing every malady you will ever encounter.
6. Web browsers
You already have a client, you’re using it right now. You can use it to poke at APIs.
7. People
Everyone knows HTTP. Quite a few people know more about it than you ever will. You can always reach out for help, or get contractors to solve problems.
8. Guaranteed web access
Corporate proxies and weird ISPs cause all kinds of havoc for things that aren’t HTTP. Being HTTP means you sidestep those problems.
9. Extensive hardware
If you’re high traffic or need extremely high uptime, you’re going to outgrow most software solutions. When you step up to the big time, hardware vendors will be there to support you.
10. Known scalability paths
Not only are there software solutions to allow easy migrations to more scalable architectures, but there are also easy patterns for designing a backend to scale up servicing HTTP’s stateless request-responses.
11. Prior knowledge
You already know HTTP. Your coworkers already know HTTP. You can start working on the harder problems at hand.
12. Extensibility
Between HTTP verbs and headers you have quite a bit of freedom to extend your original schemes. Need an extra piece of data? Add a header. Have pieces of information but want to be able to remove them? Use HTTP DELETE. Run into a really hairy problem that really wants a piece of it to be solved in a different protocol? Use HTTP protocol switching.
13. URLs
Using HTTP allows you to use a standard way of referencing resources. Parsers already exist for every language and their semantics are well understood.
14. Security
HTTPS gives you baked in easy to use security. It has its limitations, but if you’re really paranoid you can always use SSH and a SOCKS proxy. Once again, HTTP has your back. (Forgot to include this, thanks Daren Thomas for pointing it out!)
In the end the rules are simple. Is it possible to do over HTTP? Then do it over HTTP.
I’m not exactly defending an unpopular position, but there are still surprising transgressions of this rule. XMPP being the most obvious one. It’s quite a bit more complex than HTTP and is missing most of the above qualities. It’s usually cited as an example of a protocol that solves a problem http can’t: asynchronous bidirectional messaging; allowing the server and the client to send messages with minimal lag. The truth is HTTP can do this just fine, with long-polling and HTTP keep-alive you can keep a persistent bidirectional connection open.
There are an ever slimming number of commonly used protocols that aren’t http: instant messaging, e-mail, irc and ftp come to mind.
Move a service to HTTP, and it becomes a team player in our ecosystem. Let’s revolutionize the last of our dinosaur protocols and move on.
Excellent article, but I take exception to the first sentence in #5: “There are no problems that have not yet been encountered.”
You cannot say that for certain. It’s impossible to prove that ever possible problem has already been uncovered.
“It’s impossible to prove that ever possible problem has already been uncovered.”
HTTP has been around since 1991 or before, so the chances of a non-trivial problem being discovered at this point are so small they are effectively non-existent. If a major problem is discovered, it’s not going to be with the protocol itself, but rather with a particular implementation.
Well, there is the HTTP ARMAGEDDON verb, which is troubling in several ways, the least of which is that ARMAGEDDON is not a verb.
Thankfully, like PUT and DELETE, most servers do not implement it; It has most of the same security concerns as they do.
“Thankfully, like PUT and DELETE, most servers do not implement it”
Thankfully, most servers DO implement them, or at least accept them. Unfortunately, browsers do not accept them in HTML and only let you use them via XHR requests. This can/will drive you crazy once you start really using/developing REST apis.
dont forget the http overhead
Silverlight hates PUT and DELETE too, as we discovered when trying to use it with a REST API.
Messengers and IRC cand be built over http with no problems. Probably email too although the same arguments you give for using http (like well established software base and such) goes for email even moreso.
But don’t forget one of those “dinosaur” protocols that HTTP can never ever replace: bittorrent. The other one would be FTP, a true dinosaur, but a well adjusted one.
Hi, just a small tip to make your excellent post even better: Please add links for stuff like “HTTP protocol switching”, “long-polling” and “HTTP keep-alive”. I’m sure I could google this stuff, but having the links would mean that they would already be open in tabs…
Oh, and you might have forgotten to mention: Securing your connection (https) is already solved multiple times – something you would have to redo with another protocol.
“don’t forget one of those “dinosaur” protocols that HTTP can never ever replace: bittorrent”
BitTorrent could easily be implemented on top of HTTP! Why on earth not? I can’t think of any reasons at all.
“The other one would be FTP”
The only thing stopping FTP over HTTP is a commonly accepted API. Even in its absence, HTTP file transfers must outweight “file transfer protocol” file transfers by many orders of magnitude. FTP is dying, as far as I can see, and a commonly accepted API for directory navigation/listing in web apps will be the final nail in the coffin.
You’re thinking too far down, both those things are great examples of what should be HTTP. I actually struggle to think of anything that can’t be done by HTTP that isn’t realtime streaming video/audio or game networking or something, anything which is UDP basically.
Great article and as you can see, I agree 100% : )
Great article!
Simplicity and text-based are important features too.
Client and server can be written in a few lines of code.
I can see your point, but I was wondering if you could elaborate a bit on stateful protocols. REST or some equivalent is of course very nice, but I’m not convinced it’s *always* the best answer.
To use your example, a good RDBMS has a lot of features that require both server- and client-side state, starting with transactions (of course, if you can get by with a networked hash table, that’s fine; but databases can be, and are, used for more than that.) “Start transaction, retrieve data, do something, retrieve more data depending on the results, end transaction” can be very sensible if you need to make sure that the results of the queries are consistent and cannot reasonably do “something” in the database, e.g. because it involves heavy processing or access to a network service.
Obviously, SQL is better-supported and better-known than any homegrown scheme, but let’s leave that aside for now (I’m assuming you are mostly talking about new protocols, not established ones like SQL.) Even then, handling something like this over HTTP is not necessarily a good idea: it adds overhead to a performance-sensitive protocol (quite a lot if we are talking about many small queries) and anything that touches the protocol will need to be intimately aware of the details. Thus, configuring or even writing a proxy is difficult (if you want to do anything interesting), and a load balancer is very complex – although not nearly as complex as getting sufficiently-synchronized replication working in the first place. Also, there is hardly a “known scaling path”: sharding works, but can be extremely painful and essentially requires treating your database as a networked hash table, which brings us back to square one.
Maybe I’m missing something, but for applications like the above – stateful, performance-sensitive, complex – I’m not seeing how HTTP is obviously better than a binary protocol. Of course it can be made to work – but SQL is actually fairly elegant, and I’m having a hard time thinking of an equivalent HTTP implementation that doesn’t have a lot more warts (e.g. breaking the reasonable assumption that HTTP is (nearly-)stateless, breaking if used with standard proxies, etc.) And it will almost certainly be restricted to internal use, so a couple of (or even one) good client (library) will suffice.
Great article indeed, I came to the same conclusion some time ago, thanks for putting the gist of it into words!
I’m gonna have to disagree with you here.
If you need to do something very similar to what HTTP does, then sure, HTTP is a fine protocol.
However, there are a *lot* of cases out there where HTTP would be a horrible choice. Every application is different. Use what’s appropriate. Trying to force something like HTTP into every situation is going to cause *way* more problems that it will solve.
Also, note, binary protocols are typically used where performance is a very high priority, because it’s faster and more efficient. Just one example (there are many) of where HTTP isn’t the right solution.
There’s one aspect you’re ignoring: tools, accessibility, and the amount of time it takes to get going from a service definition to something that runs.
Where I work, we started writing some C++ services that talked HTTP over a cgi gateway. HTTP was really only half a protocol – it provided a way to reach a destination point but the actual structure of the messages was still up to us, so we’d just inherited a bunch of cruft/overhead (that took considerable debugging – cgi is a pita) that served as little more than a wrapper.
To this day, I don’t know of a good interface from C++ code to a robust http server. And I don’t have time to write one
We ended up moving to thrift, where you write a simple service definition, compile it, and you instantly have skeleton code in any language you want. You just implement the interface, then you’re up and running a minute later. We’ve never looked back since.
Some very good points
I love the POV — don’t reinvent the wheel, especially WRT protocols.
However, I have to ask this (some quick Googling didn’t show up any charts): what kind of overhead does http require, compared to something a bit simpler like FTP? That is, for a very specific application (e.g. FTP), what % of the packets are being consumed by the protocol as opposed to the data, relative to other protocols? (I would be very much interested to know this, actually…)
Also, it seems that for something like chat, http might not be the best for real-time communications, as it is stateless. Anyone with more of a background in protocol details care to address either of these points?
Look I’m all for HTTP, but I mean how much longer is really gonna take until we can start scaling to something else besides a web-browser. If anything the browser should stop scaling for the web and start scaling to our desktop as a virtual machine. . .something this huge would finally bridge the OS divide and create a broader platform for communicating data, text, information, video, audio, code, projects, ideas and who we share our time with and how.
Joachim Schipper: Take a look at NYTimes’ opensource HTTP -> MySQL proxy/loadb alancer. It’s a great example of how SQL can be mapped to a stateless request/response architecture: http://code.nytimes.com/projects/dbslayer.
Travis Leleu: For modern hardware and connections, FTP vs HTTP isn’t about protocol overhead in bytes at all. They’re both very cheap compared to the data blobs you’ll be sending. If there’s any difference at all, it would be in round trips (lag). An HTTP standard could have fewer (since it could be designed for modern high speed connections) and would thus outperform FTP in benchmarks… but in the end you wouldn’t notice. You’re probably transferring 100s of kibibytes or more, at which point the protocol overhead is moot.
With this in mind, have you thought about re-implementing your memcache protocol speaking WebHooks forwarder to talk HTTP instead? I’ve been thinking about this for a couple of days – it seems like having your regular web server to an HTTP POST to a forwarding service with the eventual destination URL as a query string paramater would be a really nice way to scalably implement WebHooks. The forwarder could return OK straight away (freeing up the web server to get back to what it was doing) and then send the actual POST request in its own time, maybe after a spell in a message queue somewhere.
Simon Willison: (Sorry for the delay, WordPress.com’s spam system is a little aggressive) Yes. yes. yes. The system really should be “post to /webhook/new” with a JSON blob of url, retry semantics, level of service, etc. I originally chose memcache because it was kinda nifty, and all the cool kids were doing it (Starling). Your semantics / timing are exactly what I imagine.
Originally Jeff Lindsay and I were talking about this idea (webhook post’er) as a public web service. We realized immediately the lag out to a 3rd party and the inherent unreliability meant the service wasn’t much better than directly posting to webhooks. Which was when we coined the phrase Service-as-a-Software.
“In the end the rules are simple. Is it possible to do over HTTP? Then do it over HTTP.”
That is a horrible reason to do anything. Just because its possible doesn’t mean that it fits the application. I am curious what types of applications you build. Personally I build systems that handles millions of transactions – I can’t imagine* the overhead tunneling it through http would add. Its just not an efficient protocol. Heck its even not that great as a protocol between a browser and a web server. Since its original conception we’ve been building tools and processes to deal with HTTP’s limitations – why on earth would we want to continue down that path?
*(actually I can imagine it, I can even run numbers showing why its an incredibly silly idea)
sounds like a good Idea, and you dont implement it fully, just parts you want…
Simon Willison: There’s even an HTTP response code for doing exactly that type of thing: 202 Accepted. It indicates that the server accepted the request but isn’t yet done processing it. The client would call the service, passing the callback url, the service would reply immediately with 202 Accepted, and call the callback later when the request was completed.
Anyone that knows me knows that I’m all for doing absolutely everything with HTTP
Donovan Preston: When I first met you in person at PyCon ‘05 that was my exact thought. “Somebody else that feels for HTTP the way I do!”
The reason firewalls were invented was to allow people control over what happens on their network.
The reason that HTTP is wonderful is that it allows applications to do whatever the author wants, regardless of the network owner’s wishes.
I can clearly see why this is a wonderful state of affairs, and anyone who can’t has simply failed to realise that corporations exist for the purpose of giving us free network bandwidth.
…because HTTP doesn’t do push without holding open connections. Other than that you make a good point.
Mark.
Mark Maunder: I didn’t articulate it well enough, but that’s actually a problem. The vast majority of the internet is behind a NAT, firewall or broken device and simply can’t accept inbound connections of any kind. The only solution is to make who starts the connection and who actually has to send the message completely separate issues; which long polling solves.
http://cometdaily.com/2007/11/15/the-long-polling-technique/
Timothy: Exactly. I’ve written my own proprietary long polling server to deal with exactly this issue since Cometd isn’t ready for prime-time yet. We use it for our live traffic feed product that pushes events to your browser as people arrive on your website: http://live.feedjit.com/live/feedjit.com/ [Sorry about the plug - but I guess it's relevant].
It used to be that servers couldn’t handle more than a few thousand connections, but since epoll (and equivalents) came about it’s fairly trivial to write an HTTP server that can handle tens of thousands of long-polling connections with zero cpu load. We handle well over 10k concurrent connections constantly with a single thread.
The problem is that epoll-style servers aren’t as ubiquitous as I’d like. So for example even though you have nginx or lighttpd or a proprietary epoll-style server that can handle tons of connections without killing the box, the software you mention that is between clients and servers like proxies don’t like holding connections open because they’re still design using the on-thread-per-connection model.
But we’ll get there I think.
Mark.
Right on about HTTP.
Chew on this: years and years after DNS is stable, Kaminsky finds a flaw with DNS that gives a backdoor to route legit users elsewhere.
If we go and create new protocols, new layers, it will take years to make such safe and stable.
If there’s a pressing need, I would support it. I’m unware of such need.
Chuck – we’re already scaling to something something else – RIA, and currently Adobe Flex is the winner.
HTTP is not stateful. In protocols where state is important HTTP would be a failure. (Think the NFS “stateless” debacle)
In addition HTTP is not great where realtime is required (e.g. VOIP)
-Andrew
againseminoma: I don’t think your example works nearly as well as you want it to. First of all, when it comes to security, there are a lot more implementation problems than there are protocol problems. Sure, you’ve illustrated *1* security problem with the DNS protocol. But, how many security problems can you find across all of the implementations of HTTP handling programs? Thousands?
Also, DNS is an excellent example of a protocol that would be absolutely and completely *horrible* done via HTTP. Having DNS run over HTTP would literally slow down the Internet. Every single web page would take longer to load.
HTTP has been a very good protocol, but trying to shoe-horn everything into it is a terrible idea.
The XMPP example is lame, and your very article explains why it shouldn’t be over HTTP.
Servers and clients in any language: No. The challenges of implementing an XMPP server are not located in the protocol connection, they are located in the XMPP standard, which does not trivially map onto HTTP by any stretch of the imagination.
XMPP actually has an HTTP binding, and while it does now have clients in many languages, it took a lot of work to get there, because stock HTTP client libraries couldn’t deal with the degree to which you have to torture HTTP to get instant messaging (not just XMPP, instant messaging in general) there.
Proxies: Instant messaging is highly stateful, intrinsically. Sending the presence state and avatar of every person on your roster for every request would be obscenely large. (Don’t forget, there can be hundreds of such entries.) Proxies are worthless because streams are instantly stale, so there’s no caching advantage, and load balancing is worthless because of the inherent statefulness.
Debugging tools: Optimized for requests that actually end. For endless requests, how is this any better than a packet dump?
Web browsers: There is no feasible way to render an instant message stream into a web page. Yes, you could build an AJAX app that deals with it, but that’s not the advantage you’re getting at.
HTTP knowledge: The size of an instant message standard of any kind with any sort of feature-fullness is comparable to the size of HTTP, and the working subset of an IM implementation is much larger than a working subset of HTTP. No gain here.
Known scalability paths: All of which involve taking advantage of statelessness, which is not possible with IM.
Extensibility: Not an advantage unique to HTTP. Actually, what protocol isn’t extensible nowadays?
URLs: A useless reference to an instantly stale stream. Username + server is far more effective in the IM context.
Security: Not that helpful since TLS/SSL connections are also available in libraries.
The way you get XMPP running over HTTP is with BOSH (a term you can Google), which is a gigantic cheat that violates numerous aspects of good HTTP design, but does work.
I know both XMPP and HTTP very well, and the idea that XMPP should have been designed on an HTTP base is just absurd and sullies what is otherwise a strong post. You cite a very, very small part of creating an IM connection, but miss the larger issues involved in running an XMPP service. By your own criteria of when to use HTTP, since none of the advantages of HTTP actually help IM and many get in the way and require gross hacks, you should rewrite your post to agree that IM is the canonical case of when not to use HTTP, because it’s all cost and no gain.
If we go and create new protocols, new layers, it will take years to make such safe and stable.
If we go and create new protocols, new layers, it will take years to make such safe and stable. Thank’s
We were so happy using http. We understood it! So of course people start inflicting all this other junk on us.
Christopher: In response to your comment of “I don’t think your example works nearly as well as you want it to.”
I gave the example of DNS to illustrate the dangers of revamping & replacing major or widely used protocols and layers. The DNS fiasco was a complete backdoor, available for many years. The original author of DNS had to meet Kaminsky to verify Kaminsky had indeed found a bug. Once verified, this caused multiple vendors to have to meet, including Microsoft, Akamai, Juniper, Netgear, et. al. Those vendors all had to create a patch, and synchronize deployment and release of the patch.
We don’t need thousands of “examples”, or bugs, to make this point…that one bug allowed unfretted, unmesasurable backdoor access in a technology we used for years.
That’s why I agree with y3’s statement “If we go and create new protocols, new layers, it will take years to make such safe and stable.”
I think the most of people used. Then we have no choice to not using HTTP!
[...] Why HTTP? The world doesn’t need another arbitrary binary protocol. Just use HTTP. Your life will be simpler. Originally this came up when scaling a gaggle of MySQL machines. I would have killed for a reliable proxy. It’s with this in mind that I’ve come up with my list of things that HTTP has that an arbitrary protocol will have to rebuild. Anytime you choose to use a service based on a non-HTTP protocol, look over this list and think carefully about what you’re giving up. (tags: webservices programming architecture) [...]
Excellent article – very informative and well thought-out.
You still need a arbitrary protocol to send inside the http.
Http will only add overhead.
If you don’t develop against an existing webserver(iis/appache/whatever) you will need to implement the protocol correctly yourself if you want to take advantage of all the points you listed. This requires alot more work than just opening a socket and sending the raw data.
againseminoma: I don’t think you fully understand the nature of the DNS protocol bug. It didn’t allow “unfretted, unmesasurable backdoor access”, it allowed you to spoof DNS entries for other nefarious purposes. Without some additional way to (try) to utilize the exploit, it really wasn’t that big of a deal. Also, considering that most businesses do not allow public access to their internally queried DNS servers, the risk was further limited. Regardless, the patching was handled well, and multiple work-arounds were found that often reduced the impact to negligible.
The Kaminsky DNS flaw was a major issue, yes. But it wasn’t anywhere near the worst security issue that’s been found. I’d even go so far as to say it was relatively minor in the end, despite the hype. In fact, there have been *multiple* HTTP implementation bugs that have caused *much* worse damage. A couple of IIS bugs alone were (each) responsible for worse outbreaks and damages than the Kaminsky DNS issue.
Can you provide *any* other examples of major security issues with a protocol? I can think of a few, but they pale hugely in comparison to just the implementation issues we’ve experienced with HTTP.
Additionally, you ignored the other have of my comment, regarding implementing DNS over HTTP. If HTTP is the ultimate end-all be-all protocol, as claimed here, then DNS should be implemented on top of HTTP, right? Except that this would be a horrible idea that would cause a gigantic multitude of problems and slow down all web browsing in measurable and notable ways.
Finally, even if you used HTTP as the base for your new application, unless what you were doing is *remarkably* similar to web browsing, you’re likely going to have to hack a whole lot of extra crap on top of HTTP to be your protocol. . . which still leaves you with the ability to have protocol level security problems.
Dear Timothy,
I’ve taken a good look at DBSlayer, but I fail to see how it addresses my concerns. I don´t think tunneling SQL over HTTP is particularly elegant, but let´s put that aside for now; more importantly, i fail to see how this is allows me to use the database as more than a networked hash table. See e.g. http://code.nytimes.com/projects/dbslayer/wiki/CodingWithTheSlayer, under “What if I need to link two queries together”. The NYT team points out that they cannot do the two-part transaction I described above, and that there is a mismatch between (My)SQL’s stateful protocol and DBSlayer’s stateless protocol here.
(Of course, it also has other undesirable limitations – as noted on the page, performance for large results is rather bad due to the overhead of encoding etc.)
[...] http http://timothyfitz.wordpress.com/2009/02/12/why-http/ [...]
you write a lot .
[...] implemented, it makes reading mailboxes from web scripts that much easier and accessible. And like Timothy Fitz recently suggested, this would make email a team player in our web ecosystem. « The start of a [...]
Christopher:
I fully understand the impact of the DNS bug:
“It’s a really bad bug that really impacts every web site you use and your readers use,” Kaminsky said. “It impacts whether or not readers are even going to see the article you’re about to write.”
Security researcher Dan Kaminsky finally revealed the full details of his reported DNS flaw. It turns out it’s a lot worse than previously understood.
“Every network is at risk,” Kaminsky said at the Black Hat conference here Wednesday. “That’s what this flaw has shown.”
Most of the focus has been on the danger that hackers could easily use the DNS bug to hijack web browsers, redirecting victims to malicious web sites. But this was only the most obvious of many possible attacks. In addition to browsers, attackers could target numerous other applications, protocols and services, such as the File Transfer Protocol (FTP), mail servers, spam filters, Telnet and the Secure Socket Layer that’s supposed to make online banking safe from eavesdroppers. Automated software updating systems like those used by Microsoft and Apple could also be subverted, allowing hackers to trick users into installing malicious software disguised as authenticated software updates.
Another serious vulnerability involves sites that provide the ubiquitous “Forgot your password?” link for users who find themselves locked out of their accounts. Kaminsky showed how the DNS flaw could be exploited to provide hackers with a backdoor or “skeleton key” to the web accounts. He worked with major sites such as Google, Yahoo, PayPal, eBay, MySpace, Facebook, LinkedIn and others to fix the issue before he disclosed information about that attack scenario today.
Plz read where it says “showed how the DNS flaw could be explointed to provide hackers with a BACKDOOR.” I implore YOU to READ more about the DNS flaw enabling a backdoor.
It was a very big deal – and why a bunch of high volume tech companies (please read list of names I gave above) all worked on a patch to be released at the same time. Why all those companies met privately with Kaminsky. Big deal on security, big deal at black hat, big deal in terms of the amount of money to create and apply patches.
I don’t have to ‘hack’ a whole lot of extra crap on top of HTTP to be my protocol for applications. There’s plenty of open source software to make use of SOAP & RESTful web services, delivered over HTTP & HTTPS.
I’m done with tit for tat.
K 10x bye.
The whole DNS debate misses the point. Yes, there are serious issues with DNS (and Kaminsky’s bug is not necessarily the worst), but building everything over HTTP doesn’t solve these. For one, HTTP has its own problems (e.g. response splitting). Secondly, logic flaws aren’t fixed just by tunneling over a protocol, even if the underlying protocol has no flaws of itself. (After all, DNS runs over UDP/TCP over IP over some lower-level protocol; none of these was at fault in this case.)
And anyone relying on DNS working properly is misguided in the first place. It’s plain-text, unauthenticated, and vulnerable to several theoretical and practical attacks (id spoofing cannot be fixed entirely in the DNS server; there are still far too many resolvers vulnerable to stupid things like cache poisoning; and if all else fails, an attacker on the same network may be able to spoof responses from the server.) There is a reason that sane security protocols like SSH and SSH/TLS require server certificates…
[...] Why HTTP? – “In the end the rules are simple. Is it possible to do over HTTP? Then do it over HTTP.” [...]
I couldn’t agree with you more. As a network engineer specialising in intelligent application delivery, please use HTTP. There is so many ways that the network can help to secure, optimise and deliver your application so you don’t have to. This leaves you the developer to focus on the functionality of your application.
Yup, this is why I develop web applications and not software-based applications.
[...] http://timothyfitz.wordpress.com/2009/02/12/why-http/ : HTTP est un protocole éprouvé, c’est un gage de fiabilité que de l’utiliser [...]
[...] Why HTTP? Currently 12/3 Submitted February 02, 2009 by jsuggs Tags: http! programming! technology! web development! The world doesn’t need another arbitrary binary protocol. Just use HTTP. Your life will be simpler. Originally this came up when scaling a gaggle of MySQL machines. I would have killed for a reliable proxy. It’s with this in mind that I’ve come up with my list of things that HTTP has that an arbitrary protocol will have to rebuild. Anytime you choose to use a service based on a non-HTTP protocol, look over this list and think carefully about what you’re giving up. [...]
[...] are ultimately flexible and interoperable. If you’re going to do bits-on-the-wire, Why not use HTTP? And if you’re going to use HTTP, use it right. That’s [...]
[...] do it in the mindset that Tim Bray describes: “If you’re going to do bits-on-the-wire, Why not use HTTP? And if you’re going to use HTTP, use it right. That’s all.” Not as something that needs [...]
[...] Why HTTP? « Timothy Fitz (tags: http programming protocol architecture network web networking) [...]