a restful api only uses clean urls - no url variab

Question

A restful api has to use either get, post, put or delete request methods. The behavaiour and data submitted is entirely determined by the uri string. No query paramters or post variables.

Is this true ?

Valid : http://example.com/foo/84

Not valid : http://example.com/foo/?value=84

Valid :

$.ajax({
  type: 'POST',
  url: "http://example.com/foo/84",
  success: success,
  dataType: dataType
});

Not valid :

$.ajax({
  type: 'POST',
  url: "http://example.com/foo/",
  data: 84,
  success: success,
  dataType: dataType
});

edit Two answers so far, and the contradict each other.

Answer 1

Saying that http://example.com/foo/?value=84 is not valid is not entireley true. What i mean is that as long that it is a valid URL it will work and you'll be able to get the parameters via get or post.

On the other hand, REST is an architecture and one of its demands is a clean URL (one that does not include params with a '?') so such a url is not considered a REST like URL.

So if you intend to build a REST based application, you should only use clean urls.

EDIT:

I see from the comments below you have a problem understanding what is REST so i'll try to give a simple example:

1. In order to get data you will probably use http://example.com/foo/84 as a get request and the rest FW knows to get resource foo with id 84.
2. In order to post data about foo, you might call: http://example.com/foo/84 as a POST request and now the Rest FW know that since its a post request it will call the method responsible for handling post and not the one for handling get
3. To delete, you call the same URL with DELETE action and i think you know the rest.

So, although you have the same URL it really matters if its a GET/POST/PUT/DELETE request.

Answer 2

POST variables are definitely OK otherwise how would you submit a new resource or update it?

GET parameters are fine to specify how the resource should be rendered. So indeed http://example.com/foo/?value=84 is not right - the URL doesn't represent a resource.

However, http://example.com/user/84?fields=first_name,last_name would be ok. In that case, you would use the additional query parameters to specify that you only want the first name and last name for that resource.

Answer 3

Here goes a third answer that contradicts the other two.

RESTful URI is almost an oxymoron. The semantics of the URI is irrelevant to REST, the only thing that matters to REST is that one URI identifies only one resource. Other than that, an URI is an atomic identifier, and its semantics are irrelevant.

For REST it doesn't matter if the URI pointing to a user resource for Joe Doe is:

http://example.com/users/joedoe

Or:

http://example.com/users?username=joedoe

Or:

http://example.com/jif892mfd02-18f2

Or even:

ftp://example.com/users/joedoe.json

It doesn't matter! URIs don't need to have any meaning in a RESTful application. People spend so much time designing meaningful URIs for their REST application, while they should be concerned with their media types. When you click a link on a webpage, you don't care about the semantics of the URI, you only care about the label. The same thing happens with a client using a REST API. The documentation of your media type should describe what links are available and what they do, through labels, and you simply follow them.

If you're concerned with the semantics of the URI, this is a sign that your clients are building URIs from some template in documentation, and you're not using HATEOAS, which means you're not doing REST at all.