Prompted by looking at Catalyst and Handel in particular, has me thinking about that whole REST thing again.
Seems to me that very few people get the point (and I’m not claiming I do). There’s been alot of smart debate, some even down to earth, but what does REST really mean? What are practical consequences web developers can use? How do we eliminate grey areas? Is this REST?
What I’m pretty sure of is what Roy was describing is, at heart, a very simple set of ideas, based on a simple protocol that provides everything you need. But in the endless debate vs. SOAP the point seems to have been lost.
One particular quote from the Wikipedia interpretation…
With REST [...] the emphasis is on the diversity of resources, or nouns
Turning that on it’s head, how about this as a bold statement that we can actually use:
Never put verbs in URLs
To that extent made this change so that this URL – http://www.example.org/users/search?surname=Michaels becomes this: http://www.example.org/users?surname=Michaels
Will kick off with two exceptions (but I think the only exceptions) – domain names or where the verb is actually part of the name (such as a title in a “search engine friendly” URL) like this
Think the consequences which fall out of that rule could make frameworks much easier to use if APIs get designed around it – a middle ground between this and frameworks like Catalyst and Rails which I think have inverted the problem into this form.
In Catalyst terms that boils down to controllers like;
package MyApp::Controller::Cart::Item;
use strict;
use base 'Catalyst::Base';
sub new : Regex('^(\d+)$') {
my $class = shift;
my $self = Catalyst::Base->new();
bless($self, $class);
return $self;
}
sub GET {
my ( $self, $c ) = @_;
# Do HTTP GET stuff here
}
sub POST {
my ( $self, $c ) = @_;
# Do HTTP POST stuff here
}
sub DELETE {
my ( $self, $c ) = @_;
# perhaps...
}
Will leave it there. Feel free to POST flames or whatever
Like you said, few people get the point, myself included. SOAP does well enough for my needs, but then I’ve never looked into REST to figure it all out for myself.
I’m not sure what the basis is for removing verbs from the urls though. Would you include frameworks that typically accept something akin to an “action” parameter? It is basically your verb after all. http://www.example.com/?action=search or translated as http://www.example.com/?verb=search. You’d be hard pressed to find a way to translate said url without using any verbs in the urls considering it doesn’t contain any other parameters you could refactor.
I’m also assuming that the above only applies to GET requests and not POST?
November 22nd, 2005 at 6:04 pm
That’s a fair point of view. Think the two obvious benefits of REST over SOAP for system-to-system data exchange are REST makes it easier to use the network efficiently – e.g. you can use HTTP cache headers and having very general methods like GET and POST discourages fine grained APIs (which don’t translate well to networks) plus you will probably be able to inspect a REST service with a browser.
But was thinking more of CRUD-style frameworks and normal HTML interfaces.
What about this URL http://www.example.com/results?term=PHP ?
Kind of evading the question there suffice to say another consequence is seperating “tools” for working with “resources” from the resources themselves. That might mean to edit a blog entry you might have a URL like http://www.example.com/backend/editor which displays the form you need and POSTs to the resource (URL) to update it.
Guess the encoded POST data might contain verbs but not the URL you POST to.
November 22nd, 2005 at 6:43 pm
[...] To me a direct consequence of promoting actions as first class objects is we end up with people putting verbs in URLs like “http://example.com/item/1/delete”, which in turn leads problems like this and implies tight coupling (between client and server) and RPC. GET is clearly labelled as “safe / read only” while putting a verb in a URL implies something is going to be done (which may or may not be safe); In particular, 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. [...]
December 22nd, 2005 at 7:38 am
I’m looking for an XML description of a REST service, something like WSDL is there such a thing ?
October 9th, 2006 at 7:58 pm
IMO, it would be even better if you could somehow eliminate the query string to get something like:
http://www.example.org/users/surname/Michaels
http://www.example.org/articles/term/PHP
This would make the search URIs more inline with tag URIs:
http://www.example.org/articles/tag/PHP
Of course, browsers don’t normally generate URIs like this from forms so you’d need a JS or server rewrite/redirect to get URIs like these.
October 17th, 2006 at 7:46 am
unutaopba
February 16th, 2007 at 4:03 am
I still don’t understand why verbs in URLs are bad. delicious does it and they seem pretty successful?
I plan on releasing (yet another) image hosting site. eBlarg!
I hope to structure my URLS like:
View all pictures in “Florida” gallery with “Swimming” and “Diving” tag:
http://cbmeeks.eblarg.com/pictures/gallery/florida/swimming/diving
“pictures” would be the class, “gallery” would be the function and the tags would follow.
I think this follows the “no verbs” method but I plan on doing this for tags:
Edit tag:
http://cbmeeks.eblarg.com/tags/edit/florida
IMHO, the end user (who cares less about REST) can easily remember that URL and it makes sense to THEM.
Anyway, just my opinion.
May 26th, 2007 at 12:14 am
Strike what I said back in May.
I’ve spent the last couple of months getting a much better understanding of REST.
And delicious uses a REST-RPC hybrid anyway. :-)
http://www.signaldev.com
August 14th, 2007 at 3:20 am