Cool. Some conclusions, remarks and chest-thumping:The W3C Quality Assurance Team has posted two useful notes on Common User Agent Problems and Common HTTP Implementation Problems. The former should required reading for anyone attempting to write a browser. In particular, the IE team at Microsoft really needs to read this, though they're hardly the only group out there that can benefit.
The second note should be read by anyone attempting to write a web server of any kind, whether a traditional web server like Apache, or some sort of application server like WebObjects. In particular, the section on URIs is required reading for Apple's web team, the WebObjects developers, and all the subscribers to the webobjects-talk mailing list who just noticed that I called their favorite software a piece of animal feces back in October (Actually, I was more polite than that, but I shouldn't have been.) and who persist in bombarding me with e-mails that only prove that they really don't understand HTTP. Here are a few clues for the clueless:
- All URLs should be able to be bookmarked and linked to.
- HTTP is stateless by design.
- The difference between GET and POST has nothing to do with how many characters broken browsers can stuff into a URL.
- Cookies are unnecessary for user authentication, shopping carts, or anything else.
Yes, more developers and more software operate the wrong way than the right way. This includes WebObjects, though it's hardly alone here. There are many other broken sites and broken software that behave similarly. Good library software is implemented by experts who really know their field. The software does the right thing so the developers who use it don't have to be experts in the field. WebObjects is not good software. It was obviously designed by programmers who were not HTTP experts. They may have known a lot of things about GUI design, databases, programmer productivity, and the like; but they didn't know HTTP. Consequently, they made a lot of novice mistakes that are now propagated by almost every web designer using WebObjects. WebObjects makes it easy to do the wrong thing.
If you want to argue that the Web architecture is a bad architecture, that HTTP should allow state, that unbookmarkable URLs are a good idea, and so forth, feel free; but first you have to understand what you're arguing against. Do the necessary homework to understand what the web architecture you're arguing against is (and of course whether you really want to be arguing against it in the first place). Otherwise you end looking as foolish to people who do understand the web architecture as the early 20th century etiquette books that suggested you write a letter to people you wanted to call on the phone to find out when would be the appropriate time to call look to someone who actually understands the phone system.
[from Cafe con Leche XML News and Resources]
- We've done a good job when designing xReporter. As a result, our URIs are bookmarkable, since no cookies have been used and no ugly session id is being communicated using URLs or (bah) hidden form fields. People can easily mail links to report instances to each other, even mid-flow if they want - no state in our URIs. Authentication and authorization are handled by the container, and not embedded in the application.
- I invite people to take a look at how we manage flow in our application. The flow is controlled by the back-end, but is communicated quite ingeniously to our Cocoon pipelines - simply stating OK, which resource should be LINKed to reach the next step in the flow, and so on.
- Elliotte should make sure his individual news items are bookmarkable, too. I badly need an RSS feed of his news site. :-)
Wow, this is almost the same way we do it in belts (http://sourceforge.net/projects/belts). In our case we have a generic command dispatcher (an action with configureable handlers, based on webwork/struts/maveric actions). Each action can have a number of outcomes and place the information in the the pipeline based on the execution results.
One thing we have found is that the sitemap becomes verbose. For the next major release we'll probably create a higher level xml file that generates the sitemap as misconfiguration of the pipelines is where our major errors come from.
I'm sorry. I just can't agree with you. The Apple iTunes Music Store is a fantastic example of HTTP being used in precisely the way you suggest is wrong.
HTTP is simply a protocol. It is used for more than just web pages and therefore it has no direct correlation with or requirement for bookmarkable, human readable URLs.
Also, your site (http://xreporter.cocoondev.org/en/httpinterface.html) is pretty run of the mill to below average in its UI and usability.
Please, get off yourself!
Mike
well at least the supposed weaknesses of
ie in digest-authentication was not belaboured
here. because the truth is, that it is the
most compliant of all the browsers, despite
what some reviewers have said.