4

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?

robjmills
  • 18,438
  • 15
  • 77
  • 121
AwkwardCoder
  • 24,893
  • 27
  • 82
  • 152
  • 6
    It's worth noting that REST itself simply requires that URLs uniquely identify a resource, and shouldn't impart any specific semantic meaning. A consumer of the service should treat URLs as opaque and use the principle that resource representations will contain URLS to other resources to navigate a service. Having said all that its undeniably useful as a human 'consumer' to be able to interpret a services URLs as a hierarchical structure. – Joe Feb 05 '10 at 16:09
  • 1
    @Joe: I think you've missed the point of the question, which, the way I read it, is about verbs vs nouns instead of being about hierarchy in the filesystem sense. –  Feb 05 '10 at 16:24
  • 1
    @Roger is correct, I was interested in peoples opinions on the verb in the url... – AwkwardCoder Feb 05 '10 at 16:34

5 Answers5

9

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: Understanding REST: Verbs, error codes, and authentication

Community
  • 1
  • 1
adamJLev
  • 13,713
  • 11
  • 60
  • 65
  • @SLott What about /Dictionary/English/Kick to retrieve the definition of the word "Kick"? – Darrel Miller Feb 05 '10 at 18:54
  • 1
    @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 Feb 06 '10 at 01:04
  • @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 Feb 06 '10 at 14:14
  • 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 Feb 07 '10 at 21:38
  • @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 Feb 08 '10 at 01:56
  • @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 Feb 08 '10 at 14:02
  • 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. – adamJLev Feb 08 '10 at 15:31
  • @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 Feb 08 '10 at 16:01
  • 1
    @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 Feb 08 '10 at 20:33
6

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
  • 363,080
  • 75
  • 446
  • 653
  • 1
    @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 – AwkwardCoder Feb 06 '10 at 16:15
  • 1
    Rest URLs is an absurdity and microformats are just completely uneducated in this matter. Upvoted. – SerialSeb Feb 08 '10 at 08:30
  • I get the point but this seems pedantic, you clearly understand the underlying question that is being asked even if the phrasing is wrong. He was asking if the path he's using is bad form. – Alkanshel Apr 19 '18 at 01:58
  • @Amalgovinus: It cannot possibly be bad form because the form is irrelevant. HATEOAS means that you *follow* links. You don't read them. Therefore, it is completely and utterly irrelevant what the URIs look like. – Jörg W Mittag Apr 19 '18 at 02:05
  • If I'm to produce an API for other developers to monkey with, HATEOAS isn't a philosophy I'm going to follow. – Alkanshel Apr 19 '18 at 06:02
  • @Amalgovinus: HATEOAS is not a philosophy. It is one of the constraints that is defined by ReST (and the most important one of them). The question *explicitly* is about ReST, the OP mentions ReST twice in the body, once in the title, and has tagged the question with [tag:rest]. I don't see how completely ignoring ReST in a question that is purely about ReST is going to help the OP. There are other architectural styles for architecting Information Systems, and Roy Fielding himself has pointed out time and again that ReST doesn't really make sense unless you architect something that spans … – Jörg W Mittag Apr 19 '18 at 06:07
  • … multiple organizations and multiple generations, but that is irrelevant. The OP is not asking about some other architectural style, he is asking about ReST, so the answer is about ReST. – Jörg W Mittag Apr 19 '18 at 06:12
5

Better way would be to have /API/User/7123 and use GET/POST method to signify operations

epitka
  • 17,275
  • 20
  • 88
  • 141
3

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.

Nick Larsen
  • 18,631
  • 6
  • 67
  • 96
1

/API/User/GetUser is not RESTful. Using a verb to identify a resource is not good thing. The example url is still valid but that doesn't make it right either. It is as wrong as the following declaration

String phoneNumber = "jhon@gmail.com";
j0k
  • 22,600
  • 28
  • 79
  • 90
Abrsh
  • 11
  • 1