HTTP Developer's Handbook

honestpuck writes "To say that understanding HTTP is crucial for web development might seem like saying water is wet, yet many people don't take the time to fully understand the protocol. This book could be a good help. HTTP Developer's Handbook from SAMS gives you a great deal of information about the protocol in a clearly understood fashion." Read on for the rest of honestpuck's review.

HTTP Developer's Handbook
author	Chris Shiflett
pages	280
publisher	Developer's Library/SAMS
rating	6 - Serious flaws
reviewer	Tony Williams
ISBN	0672324547
summary	Mixed volume with fair look at HTTP protocol

One of the strangest feelings I've ever had reading a book is that I have a better opinion of it than does the author. Shiflett spends most of the introduction convincing the reader that this is a useful book and it seems that the start of most chapters is another few sentences telling me why the chapter is incredibly useful for me to read. I felt like yelling "I'm convinced, I'm convinced."

The book is broken up into 6 parts: 'Introducing HTTP,' 'HTTP Definition,' 'Maintaining State,' 'Performance,' 'Security,' and 'Evolution of HTTP.'

The first section and a large part of the introduction are the sort of information that is covered elsewhere in just as good a detail: it basically covers the obvious. The second section covers the HTTP protocol itself, with a good discussion of requests and responses, including all the nitty gritty details of the headers in some detail. This is the really useful heart of the book and it covers 80 of the 280 pages. The third, fourth and fifth sections give a too-concise look at their subject matter, I felt the book could have given much more detail here. The last section is a waste of space; in this volume I don't really need to have a small amount of information about SOAP and XML-RPC.

This book is well-written; I believe its two fatal flaws are that Shiflett seems unsure of his own book and that the book itself tries to offer everything for a developer while explaining it all for the newcomer. I think that had Shiflett given up on the newcomer and given the developer greater depth (with a lot more examples) he would have delivered a much better book. For a developer, the volume is much too light on example code, the book is not really 'practical,' more 'informative.'

This might be a good volume for a library, either a corporate or school library. It provides the salient information in one spot in a concise and readable manner. I think that an individual might find it a less than totally useful book for the money -- you're likely to have already have a volume or two that covers most of the information, and with most languages in web development having libraries that take care of most of the low-level stuff for you, it becomes less and less necessary to really understand the bottom level. Personally, I'll keep it for the 80 page section on the HTTP definition so I have it all in one spot.

---

You can purchase HTTP Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

The specifics of HTTP are not vital knowledge

[heironymouscoward]

Every developer should be forced to write a simple HTTP server just so that they understand the basic mechanisms of the protocol. But the full details go way, way beyond what I'd expect someone on my team to know (or spend time learning) unless they were writing a server, a HTTP client, or low-level HTTP interface functions.

An efficient developer is one who is protected from the details of the technical world, and who can spend his energy and time on the functional aspects of his problem.

That's my conclusion after 20 years of (mainly successful) software projects.

Re:HTTP knowledge required?

[Khomar]

I respectfully disagree. Afterall, the argument could be made that an understanding of HTML really isn't that important; rather the web developer should spend their time getting to know Dreamweaver or Frontpage. There are several problems with ignoring the basics. For one thing, when you find yourself in a situation where either the tool is unavailable or the tool cannot accomplish the desired effect, you have no idea how to proceed since there is no understanding of the framework (ie. A Frontpage designer trying to fix their HTML). Also, as fewer people understand the basics, there is less innovation and more inefficiencies. For example, knowing how memory allocation and character string structures work helps make string generation faster in code. If you didn't know any better, you might concatenate a string one character at a time not realizing the incredible inefficiency you have just caused. Libraries and tools are great for making our jobs easier, but having a knowledge of the basic building blocks is essential to know how to use those tools wisely.

Lastly, by understanding the basic framework of things, it also allows you to develop and design new improvements or innovations on the older ideas to increase capability or efficiency. If we forget the building blocks, we severely limit our potential down the road by locking ourselves into the inadaquacies of the past.

Education is never a bad thing. Ignorance is.

Re:I barely understand the acronym...

[da3dAlus]

I'm assuming this is a joke, but I don't see where anyone caught the obvious. If you count Hyper and Text as 1 word (as several people seem to do), and you don't count them as a hyphenated word, then you get Hypertext Transfer Protocol...now what about that 2nd "T"? :)

Re:HTTP knowledge required?

[ceije]

I'm not convinced that web-developers need a knowledge of HTTP.

For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server.

I think that for a programmer or admin working on a web site of any size, it's good to have a basic understanding of HTTP. It's doubly important for those working on a large site. I work at a pretty heavily-trafficked web site and when we were looking for performance improvements, the first thing we did was look through Apache release notes. We found that an HTTP issue in the version of Apache we were running at the time caused graphics that were distributed across mutliple servers to be treated by web clients as different files, hence not cached.

By removing the inode portion of the entity tag (ETag) response in HTTP headers we were able to get a 40% reduction in files served because of client-side caching, which reduced the last byte page load times for most users, and allowed us to repurpose several web boxes to serve dynamic pages.

It was a really trivial fix that made a big difference to user experience.

Re:w3c

[[e-mail]]

So, in summary... if SAMS published it... it probrably sucks ass.

Then take a look again. Their mod_perl Developer's Cookbook is great (on my list of Ten Great Non-O'Reilly Books [petdance.com]), and I really enjoyed The Ruby Way. (Full disclosure: I've done tech editing work for SAMS.)

No publisher is consistently brilliant, nor consistently awful. It may be an indicator, but ignoring a publisher because of a product line you don't like is self-defeating.