in reply to Re^2: Falling for the same trap - since 1942
in thread Falling for the same trap since 1942

What he's saying is that it should be followed if you want to make your life easier.

Do you (or does he) care to elaborate? I think it depends on requirements. It is a convention, and so it often is followed. OTOH, it's just a convention, and it often is not followed. I think the current state of affairs has come about by real world pressures. Without explanation, I think the gentleman is, at best, oversimplifying.

Well, keeping in mind that it is assumed that your GETs never change server state, then it makes a lot of sense considering the problem he is trying to address.

I must be missing something. What's the problem he is trying to solve with redirects?

Note that if you think I "accused" you of writing C-ish Perl, then at the same time I "accused" myself of writing LISP-ish Perl.

Oh, I know. And I did take it a bit personally, I guess. Really, that's because of the associations to both C and LISP that I have in my own mind. Things like... LISP: pure, clean, fun. C: applied, messy, work. It's also ingrained into me that "writing C in Perl" is something to be avoided. I do know that your comment wasn't pejorative, though. ;-)

"My two cents aren't worth a dime.";
  • Comment on Re: Re^2: Falling for the same trap - since 1942

Replies are listed 'Best First'.
Re^4: Falling for the same trap - since 1942
by Aristotle (Chancellor) on Jul 15, 2003 at 22:06 UTC
    What's the problem he is trying to solve with redirects?

    Refreshing. If you POST to a URL, then get back a page, and then try to refresh that page, you have to resend the POST data. If on the other hand, any URL you POST to produces a redirect, then refreshing will reload from the URL the refresh pointed you to, rather than the one you POSTed to.

    It is in this context that following the GET/POST convention is most natural; of course, you can apply the general "redirect after everything that changes server state" even if you don't. Personally, I don't consider the "POSTs must have side effects" rule nearly as strong as the "GETs must never change server state" counterpart.

    LISP: pure, clean, fun.
    Don't forget "slow" and "memory hungry", esp in the case of LISP-ish Perl. And though I was referring to these connotations as well, I don't see what's so bad about being pragmatic? :-)

    Makeshifts last the longest.