You got that mixed up. Idempotent requests mean that the result is exactly the same even if issued multiple times. In the case of a logout, idempotency is pretty much granted even when using GET requests. The idea here is that GET request should not change the state of the application, because the browsers are happy about opening the same URL multiple times without user confirmation. For instance, a "post/delte/last" URL that deletes your last post would be a terrible idea, because of the following scenario:
1. The user goes to the "post list", */posts*
2. The user hits "delete last post", and the web sends him to */posts/delete/last*
3. The user goes somewhere else, */somewhere*
4. The user decides he would like to go back, and clicks "back". His browser opens */posts/delete/last* without any warning. _Ops!_ he has just deleted another post without even noticing!
In math/CS, "idempotent" means "has the same effect when done 1 time as when done n>1 times."
In HTTP, GET requests are often described as "idempotent" by someone who actually means "nullipotent" (i.e. "has the same effect when done 0 times as when done n>0 times"). This is because the spec describes GET, PUT, and DELETE requests as idempotent - which they are, it's just that GET requests are nullipotent as well.
Wikipedia mentions this briefly:
Therefore the results are different for different states and it is not idempotent.
In this case, logging out multiple times does not change anything from the first application.
sending notifications, updating counters, etc. all could be result of logging out.
Now, you got a point about idempotence from the server's point of view. However, it would take a _badly_ programmed website for the logout operation to _not_ be idempotent. Sending notifications, updating counter, etc. _without first checking if the user is really logged in or not_ is simply moronic. This simple check is what would turn the logout operation into an idempotent one in the server too.
No, from all states, the result is that you're logged out.
Similarly, changing a customer's address is typically
idempotent, because the final address will be the same
no matter how many times it is submitted.
Edit: Next paragraph says:
This is a very useful property in many situations, as it means that an operation can
be repeated or retried as often as necessary without causing unintended effects.
With non-idempotent operations, the algorithm may have to keep track of whether the
operation was already performed or not.
The HTTP spec clearly talks in terms of the effect of sequences of repeated operations, not in terms of the results of individual operations. The side effects of a single logout are the same as for 6 - you are logged out and whatever logout triggers exist are executed once.
CDNs - Make sure you add a Cache Control (max-age) header to your CDN sync. This doesn't happen automatically through most syncing mechanisms. Helps you save on those pesky HTTP requests that cost $$$.
Gzip - Do not gzip images. It's not worth it. For HTML/JS - YES!
POST - Always redirect after a post request to prevent reloads causing re-submits.
Forms - always have a submit button for accessibility.
Usability - Try using your site with a screen reader, don't neglect vision impaired people. (there are apparently a lot of them!)
data-x attributes will destroy your W3C validator checks. Use them if that's not important. (sometimes it just is...)
For external scripts that use document.write go take a look at Writecapture. It's a document.write override which will make your external scripts asynchronous. (https://github.com/iamnoah/writeCapture)
I don't see why counts and pagination are such a big deal. Have done them correctly multiple times. Faceting might be hard though ;) It's a useful usability feature to show counts. (or atleast show counts when there is nothing - i.e. a zero count)
Those are the ones that I could think of right now. :) Great article, some good points in there!
Regarding Ajax I just wanted to make clear that it's pointless to wait for the redirect... even if it's send back as response it would not cause anything like showing a different page afterwards.
> data-x attributes will destroy your W3C validator checks. Use them if that's not important. (sometimes it just is...)
Are you sure that is still the case if you have the HTML5 doctype?
It'll probably be finalised by 2014. I don't get the down votes, if you don't agree then why not ask/explain why ?
Also, as we all know by now, XHTML doesn't make any sense with the browsers that exist – particularly as it's rarely actually valid XML, and even rarer, sent with the right MIME.
In short, XHTML doesn't exist in any practical sense and HTML5 subsumes HTML4 + modifying the stupid bits to fit with what browsers actually do. There isn't really any logical reason to not use HTML5 syntax, though of course, using the new features can be problematic.
I understand that your logic for validating is likely your companies decision and not your own view, and I'm not attacking your values or opinions in anyway.
As long as we're talking client-side, I couldn't agree more. It seems no matter how much I try to make things "easier" with YUI Loader or some clever AMD + loader solution, it always turns out to be a headache.
Could someone expound for the ignorant?
: Post from my blog, but I'm not linking to it because the rest is not useful to answer this question and I don't want to come across as a self-promoting-link-whore :)
Pagination is a mess on Reddit and HN, so maybe he considers pagination "hard to get right"., since no social news aggregator gets it right.
I just run: optipng -o7 *.png
This is not accurate at all for iOS Safari and Chrome... I just wrote some scroll-based events earlier this week and they work just fine.
There is some good stuff mixed in here but a lot of it is misleading, poorly defined, or just flat-out wrong. The most accurate stuff is extremely common sense like "staging environment should mirror prod" "don't use == (JS)" "don't use doc write (JS)" etc
Because most of this stuff is not applicable to webdev in general...