http://gofrontrow.com/info

or

http://gofrontrow.silly-email-delivery-company.com/sdfghk2457y2rfhid

ugh

Let me repeat, SOAP is a nightmare. RESTful web services are the way to go. If you need high-availability, use Amazon EC2 or something similar.

By what appears to be your definition, every search form that doesn’t specify a method would be unsafe if the developer of that form made any attempt to save given search parameters for their own analysis. The very fact that SnipURL retaining an index to match what you provide them to what they provide you caused you to broadcast your overinterpretation of a standard to the world is hilarious!

What action, in terms of adding an index entry into their database, might have an unexpected significance to you or others? Their use of get with an underlying database entry on their end does not fall outside of the standard. You are a standarista.

addons.mozilla.org

Remember AMO, remember it all.

Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in /home/welldesi/public_html/wiki/includes/Exception.php on line 114

I also noticed that I almost never type the www anymore, anyway. Except for a few sites I know where I get nothing without the www and they constantly annoy me. It’s also not nice to the user to issue 404s in that case, imho.

<a href="whatever"><button>Clicky</button></a>

I just found about this blog, looks like I’ll be reading it often!

Using GET for unsafe operations is something I have been fighting hard against on a web app. Months later, the devs started using buttons on the UI for things that were “actions”. But keeping GET. And not only that… They didn’t even use a form!

Clicky

I kid you not.

Then it was discovered a button in a link doesn’t work on some browsers. So now the button’s onclick handler (yup, Javascript) uses location.href to go to the correct URL, with GET of course.

I’m gonna kill somebody.

I agree with your push for well-designed URLs and simple, RESTful practices. But I must admit I’m not sure you’re correct in this critique of SnipURL’s API.

It’s true that one should only ever use GET for idempotent queries, but the standard doesn’t actually mandate that GET must always be safe. (I’m using “idempotent” and “safe” here as the standard does: loosely, idempotent means “doing it ten times is the same as doing it once” and safe means “no side effects”.)

And here I quote from the HTTP spec, section 9.1, http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (*emphasis* mine):

“… the *convention* has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered ’safe’. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.”

“Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, *some dynamic resources consider that a feature.* The important distinction here is that the user did not request the side-effects, so therefore *cannot be held accountable for them.*”

So according to the spec, the “safeness” of GET is a (good) convention, but its idempotency is a requirement, as the next sections make clear. Note also the spec specifically says that “some dynamic resources consider [GET with certain side effects] a feature”. SnipURL are obviously okay with being “held accountable” for the side effects if the user didn’t intend them (and almost always he will have intended them).

The reason this doesn’t matter with something like the SnipURL API is that you can repeat the “snip a URL” operation as many times as you want, and it always returns the same result. So the operation is repeatable, cacheable, spiderable, etc. (This is in sharp contrast to other operations where you definitely need POST, such as commenting on a blog, transferring money to someone’s account, etc.)

As it happens, I run a similar service at DecentURL.com, and early on a guy convinced me to change the main “make a URL decent” action from POST to GET — because a GET is simpler to use in many contexts, and since the action is idempotent, everything’s cool. As he put it:

“From the browser’s perspective, there is no difference than if the response had always existed for all time prior to the first request. One can cache that response without any perceptible effect, for instance, and bots can request it again and again without damaging anything.”

So apart from the fact that SnipURL and DecentURL *do* actually adhere to the standard … also note that you’ve got to be somewhat pragmatic about these things. Most other URL redirection services out there use GET, and it works fine, for the above reasons. As Paul Buchheit said on the GET vs POST issue, “I’d rather have something imperfect but useful and popular than something ‘perfect’ but unfinished and unused.”

Sorry about the long comment. Hope this helps clear up why using GET here is not only okay but also standard. :-)

Cheers,
Ben.

In an effort to provide the best possible customer experience, this page has been removed.

And no - there were no links on it to any of the missing downloads, nor can the site be searched - google was the only thing that found them again…

First, and most pedantic, Mike’s quote from Avi is not exactly a clear example of confirmation bias. It seems more like an “Appeal to Ignorance”. that is “There’s no evidence for X, so it must not be true” Confirmation bias is more like “There’s some evidence for X, so it must be true”.

Second, REST is not about pretty URL’s. REST and Pretty URLs have very little to do with eachother. And while you may think you’re being clever, and subverting REST with your seaside framework, as long as you’re using HTTP, you’re using REST architecture whether you like it or not. The question here about seaside’s state model then, is not about whether it’s RESTful, but whether or not its breaking the expectations of the client application (Either a browser, or a search engine, or other client).

That is, the worst crime of session state is that it breaks the back button, it breaks bookmarking, it breaks the user expectation of what happens when they send a friend or college a web address. Basically, session state, (and also Ajax) are a really bad idea for the same reasons that frames were a really bad idea. It may seem in the heat of the moment a really convenient way to get things done, but the end result is a broken website.

The worst part of it is that Users, and consequently, web developers, who are also users, don’t see anything wrong with breaking the back button, or breaking bookmarks.

REST architecture, it’s true, is not necessarily the best architecture for an application- But it is a really good architecture for designing applications that must work over a network- The constraints of REST are not there simply to annoy desktop application developers, they’re there to force you to SIMPLIFY your application’s design in such a way that it is robust against network failures, slow connections, allows proxies and caching, and other really good features that Ramon seems perfectly happy to throw away without a second thought just to make his website a little easier for him to program.

So what we have here is a design decision that costs the users dearly by breaking their browser, harming usability, making the application perform very poorly over a network, for what? To make it a little easier for you to program? This doesn’t seem like a particularly professional attitude to me.

The concern for me would be someone highjacking URLs from their system and pushing them to another location other than the snip’d url.