Is this a bad REST URL?

Question

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

Answer 1

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.]

Answer 2

/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";

Answer 3

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

Answer 4

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

Answer 5

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.