I've just been reading about REST URLs and seen the following example:
/API/User/GetUser
Now if this is accessed over HTTP with a verb GET isn't this a bad URL becuase it describes the action (GET) in the URL?
+8
A:
It's more of a convention, than a hard rule, but I would rather see something like /API/User/7123. The GET/POST/etc describes the action verb, so also putting it in the url makes it redundant.
And in this situation there's no reason not to follow good proven practices.
Here's some good stuff: http://stackoverflow.com/questions/2001773/understanding-rest-verbs-error-codes-and-authentication
Infinity
2010-02-05 15:57:41
+1: A verb should not be part of identifying a resource.
S.Lott
2010-02-05 16:00:11
@SLott What about /Dictionary/English/Kick to retrieve the definition of the word "Kick"?
Darrel Miller
2010-02-05 18:54:59
@Darrel Miller: The token "Kick" is not being used as a verb; it's being used as a string of graphemes to identify a particular word. It's not a verb because it's being used as instructions for what to do. It's just characters.
S.Lott
2010-02-06 01:04:35
@S.Lott In a REST interface URIs are supposed to be opaque to the client, so they are all just characters. The problem is we have a cargo cult situation where everyone seems to know that there should be no verbs in the URI but very few know why.
Darrel Miller
2010-02-06 14:14:47
When people put verbs in URLs there are potentially a few negative side-effects. First it can be very confusing to the interface consumer, especially when the behaviour of the HTTP verb and the verb in the URI contradict. Second, it can lead people to violate the expected behaviour of the HTTP verb. The classic example of this is using 'GET /myresource/delete' operations. However if you look a number of examples you will see something like 'GET /myresource/edit'. This may be perfectly valid, it may not, however, you cannot say it violates REST because there is a verb in the URL.
Darrel Miller
2010-02-07 21:38:33
@S.Lott No that is absolutely not what I am saying, but we are obviously not communicating well in this medium, so lets give up before this thread deteriorates any further.
Darrel Miller
2010-02-08 01:56:11
@S.Lott A verb CAN be part of the URL as long as the uniform interface is not violated. Having a verb in an URL is a "smell" that indicates the uniform interface might be violated, but you cannot tell by just looking at the URL. Personally, I would not put a verb in an url, but that is just my preference.
Darrel Miller
2010-02-08 14:02:13
I think what Darrell is trying to say is that people follow rules without knowing why, including the RESTy URI conventions. I agree to that, people should take a minute to understand/find out why we follow these conventions, there's a reason.
Infinity
2010-02-08 15:31:19
@S.Lott I think you know exactly what I am saying, but you are trying to be the last person to comment in the thread and would like the final comment to put words in my mouth that infer I agree with your original statement. Surely you have better things to do.
Darrel Miller
2010-02-08 16:01:13
@Darrel Miller: I'm a web services architect. I'm trying to understand web services architectures. I'm trying to understand your point. I'm trying to get a definitive "Yes" or "No" on your opinion of verbs in URLs. If your opinion is "Yes", I'm trying to get a definite rationale for that Yes without a specious example or a code smell. From your last comment, however, it appears I should stop trying to fully understand your point and stick with my superficial non-understanding. I simply wanted to understand your point.
S.Lott
2010-02-08 20:33:02
+2
A:
This is not necessarily bad... it has more to do with the framework you are using to generate your rest URLs. The link @Infinity posted is a good resource, but don't limit yourself to a set theory because it can cause an excessive amount of work in certain frameworks.
For example, there is no reason why you wouldn't want to run a GET on /API/Users/{id}/Delete to display an "are you sure" type of message before using the DELETE method.
NickLarsen
2010-02-05 16:02:02
+5
A:
Better way would be to have /API/User/7123 and use GET/POST method to signify operations
epitka
2010-02-05 16:04:39
+4
A:
GET /API/User/7123 to get user 7123.
PUT to /API/User/7123 to create user 7123.
POST to /API/User/7123 to update user 7213.
DELETE to /API/User/7123 to delete user 7213.
As others have said, REST is not a hard and fast rule, more an approach.
Use the http verbs to achive actions based upon a resource location (URL).
But mostly do what is most appropriate for your needs.
EDIT: Remember though, the verbs are about defining the intended semantics of the communication and not the server implementation.
runrunraygun
2010-02-05 16:23:27
REST is actually a set of hard and fast rules. You are free to break them at will, but don't expect to gain the benefits that you should get from a RESTful system. And non of the rules say anything about verbs and nouns in the url.
Darrel Miller
2010-02-05 19:04:22
I would even go further: REST is *nothing but* four hard and fast rules. (Actually, I believe that the first three are just pre-requisites for the HATEOAS constraint. Also, I believe they are common sense. So, it's really just *one* hard and fast rule.)
Jörg W Mittag
2010-02-05 20:05:34
@Darrel, None of the rules say anything about verbs and nouns in the url, nor does my answer.
runrunraygun
2010-02-05 21:50:48
@Both, According to this wiki page REST is an architectural style which would be at odds with your description of "hard and fast rules".http://en.wikipedia.org/wiki/Restful#Concept
runrunraygun
2010-02-05 21:51:38
@Jorg, HATEOAS is a set of constrains based on the REST concept but REST and HATEOAS are not one and the same.
runrunraygun
2010-02-05 21:57:21
"recommended conventions" for RESTful URLs http://microformats.org/wiki/rest/urls
runrunraygun
2010-02-06 11:38:58
@runrunraygun You answered a question about "Bad REST Urls" with a suggestion for URL structure. By doing that you become part of the problem. As for the microformats article, those are Rails conventions, not REST conventions. Roy has been specific in saying that REST interfaces should not define fixed resource hierarchies in the URI space. The server should be free to change URI's without breaking clients.
Darrel Miller
2010-02-06 14:11:10
+3
A:
There is no such thing as a REST URL. In fact, the word REST URL is pretty much an oxymoron. The Hypermedia As The Engine Of Application State Constraint guarantees that URLs are irrelevant: you are only ever following links presented to you by the server, anyway. You never see, read or type a URI anywhere. (Just like browsing the web: you don't look at the URL of a link, read it, memorize it and then type it into the address bar; you just click on it and don't care what it actually says.)
The term REST URL implies that you care about your URLs in your REST architecture. However, if you care about your URLs in your REST architecture, you are not RESTful. Therefore, REST URL is an oxymoron.
[Note: Proper URI design is very important for the URI-ness of a URI, especially the I part. Also, there's plenty of good usability reasons for pretty URLs. But both of these have nothing whatsoever to do with REST.]
Jörg W Mittag
2010-02-05 20:05:37
There is no such thing as a REST URL? Microformats would disagree http://microformats.org/wiki/rest/urls
runrunraygun
2010-02-06 11:38:20
@Jörg - I understand your point but in the real world where you have developers creating RESTful APIs that are accessed via HTTP I have to consider this to try to understand their thinking
AWC
2010-02-06 16:15:57
Rest URLs is an absurdity and microformats are just completely uneducated in this matter. Upvoted.
serialseb
2010-02-08 08:30:17