Do REST API URLs have to look like this?

Question

Is it true that to implement a RESTful API, one has to implement a URL structure that looks like this

http://example.com/post/
http://example.com/post/123

where the /123 would be used for edit, delete

Another way to ask the question is: can a URL that looks like this be called RESTful?

http://example.com/script.php?method=get_title&blogid=123

Solution 1

You don't have to design your URI structure like that. It could also be /some_obscure_string/base64_encoded_title/unique_id. This could also be RESTful, depending on several other factors.

But there are several best practices on how to design URIs in a RESTful web application and being as simple and as human readable as possible is one of them.

Your example http://example.com/script.php?method=get_title&blogid=123 could also be RESTful, but the query parameters indicate that some kind of RPC- or RMI-over-HTTP is used instead.

To sum it up: Don't put too much thought into your URI design. This will come automatically with a good and proper RESTful design of your application.

Solution 2

The Idea behind REST is that every resource has it’s own URL and you use the different HTTP methods to interact with those resources. It makes sense to define the URL structure so that the hierarchy between different resources is reflected in the URL, but you don’t have to.

If you have URLs like this

 /all-posts/
 /first-post
 /some-stuff/second-post
 /third-post

you still could provide an RESTful API to this. The Idea is that a GET to /all-posts/ returns a list of the URLs of every post object and the client uses those URLs to interact with the resources. Basically the URLs should be treated as opaque data by the client.

As long as the URL that is embedded in the client doesn’t change you also could change the structure without having to change the client.

Your example URL probably doesn’t belong to a RESTful API, since it contains a method get_title. In REST a URL represents a thing. What is to be done with the thing (should it be modified, should it contents be retrieved, ...) is not part of the URL, for that REST uses the different HTTP methods.

Solution 3

A key aspect of REST is that the url is the resource. a uri like

http://example.com/script.php?etc-etc-etc

doesn't put the resource identifier in the resource portion of the uri. that's not to say that a RESTful API shouldn't ever use get parameters; in fact, that's just fine:

http://example.com/posts?sort=date_asc&offset=20&limit=10

might be a great way to get the URI's of the 3rd page of oldest posts. However, using get parameters in this way should only be used in requests where the method is also GET. PUT and especially POST methods should really use simple uri's with the resource that will be affected in only the path portion.

Solution 4

RESTful URI design is all about resources access and they should be structured in the RESTful manner, so you should not have any query strings.

e.g. of GET

authors/

authors/1

authors/1/books

authors/1/books/10

authors/1/books/10/summary

etc.

Anything and everything is called RESTfull these days, just look at some of the responses by it's inventor Dr Roy Fielding and you'll get some ideas. It is worth doing some reading on the subject.

P.S you do not need post,get etc in your URIs, HTTP protocol is at present mostly used for consuming REST APIs and you can pass verb as a part of the call. Also there is a concept of content negotiation i.e you can request any available format from REST API (json,xml atc).

Solution 5

The REST concept is really based on the fact that it is URL driven, and not driven by large data-blobs. With REST, you don't have to pass a giant soap request to invoke a method - your method call/object creation/whatever you want to do is invoked simply by the URL, and the verb you used vs that URL.

View more solutions