Do the exactly same thing from
Amazon.com (note the rampant
use of method="post" in that page), and nobody complains.
Even though all of the requests do little more than request
information.
When
Tim Bray talks about
admonishing
people, I have to wonder if he took the time to reread that link
before posting. It talks about three benefits to URI's in
section
2. How many of the three apply to the dynamically created
URI based on the request parameter scenario that we are talking
about here?
Ponder specifically how the key is handled. Does this
truly help to identify a new set of resources, or are we merely
passing an argument to a remote procedure here?
Now let's get a bit more esoteric. The same article that
Tim points to says that GET should only be used for
safe
interactions. In the HTTP protocol, this is refered to as
idempotent. Is this request, containing a key,
idempotent? The expressed purpose of the key is to
ensure that the request follows the terms and conditions of the use
of the API. Call it enough times in a short enough period of
time, and the response changes.
Shining example of pure REST? I think not.
If I do the same query to Google over a long enough time the results for that will change too.
Joe, so will stock quotes and simply refreshing this page.
That's not the issue. The question is whether or not the request itself is side effect free. Idempotent to use the jargon. This is an important tenent of web design and REST. And is right there in the definition of the HTTP protocol itself.
Will the web melt down because Technorati has an API? No, it will survive this and a lot more. However, I do take issue with this being described as about as purely Webby a thing as you can imagine.
Tim Bray also completely misunderstood that I had already implemented the API and my feedback was based on that. In an email just now he implored me to actually implement it. Arrrrrgh!
I understand where you are coming from Sam. The Technorati API is great new and I'm glad Sifry implemented as he did -- a couple of lines of Perl to do a GET and parse it with a regex and bang! Technorati at my disposal.
This post from Paul Prescod adds some additional and interesting viewpoints on the "esoteric" subject of idempotency. Specifically: "I think that using a slightly broken GET is better because it provides a better upgrade path to those who wish to build apps in free-loader mode and shift them to pay-mode later." He goes on to explain that if a service caps its usage sufficiently high enough for the average user the illusion of idempotency is created. Paul also mentions that using HTTP authentication would be a better solution than embedding keys in URIs.
Timothy: I agree with Paul's analysis in that article. I met with Paul before that was written, discussed the subject with him, and reviewed it before he posted it publicly.
Architecturally, this API is RPC. If you want to talk "purity" from a REST perspective, then this particular API should be done as a POST.
However, there are pragmatic considerations to be dealt with. This gets into gray areas and personal preferences.
Tim concedes that an XML based protocol would be easier for programmers. Others may debate this point, but that's Tim's stated position. But he claims that the technorati API is the correct implementation based on purity arguments. This is what I disagree with.
Sam: The expressed purpose of the key is to ensure that the request follows the terms and conditions of the use of the API.
I'd say the key is used for authentication purposes.
Is this request, containing a key, [safe]? Call it enough times in a short enough period of time, and the response changes.
Well, yes. (Would you say it wasn't safe if there were no limit to the frequency with which you can use the service? Would you say it wasn't safe if you sometimes received a 503 Service Unavailable HTTP status code (and possibly even a Retry-After header) as a response? Does knowing the logic that limits the availability of the service make the interaction not safe?)
For a stab at a nice and RESTy implementation, I would suggest "better" URIs (I know this is fairly vague, but I'm not just now reading what Technorati is about, so I don't feel I can suggest anything), using those same URIs for access via browsers; HTTP authentication instead of key, HTTP's content negotiation instead of format, etc.
REST is hard to understand and implement. If it was easy, people like Tim Bray wouldn't write multiple essays about it and smart people like Dave Winer and Sam Ruby wouldn't be endlessly debating it. I personally think REST is a better philosophy...
Given that, as Arien suggests, one considers the key as an authentication token, why not construct a custom HTTP header with it in there?
I mean, for the appropriate GET uses, it ought not to be part of the URL right? Makes it hard to link to.
On the other hand, REST dosent like us to use cookies or any similar HTTP header mechanism to convey information orthogonal to the resource itself.
I've always had some trouble understanding why you wouldnt want to do this(minus the opaqueness that it brings), because it would seem to be an acceptable solution for both GET and POST. For the latter, one could repeat it in the API/Body or envelope part if one is using something SOAPy or XML-RPCy, or in the body for direct POST.
Steven is triggering me again... can't say I relate to the conclusions he's making: there _are_ libraries out there to handle both HTTP and XML bindingbut I do agree that ReST seems to remain a grass-root movement, which quite naturally fosters a...