Are *.local service URLs RESTful?

Question

A URL supposedly locates (and not simply identifies) a resource; a corollary is that the same URL must refer to the same resource. However, this rule would appear to be violated in the case of URLs like http://api.local/orders/333, in which api.local does not resolve to a host for everyone, and may not even resolve to the same host in the case that it does resolve. (For example, you might point api.local at one host in the development environment, and another in the live environment.)

1. Strictly speaking, are URLs with a hostname like api.local (or 127.0.0.1) RESTful?
2. Are there any problems this approach might cause?
3. Are there any good alternatives? (Which is better: http://flickr/ or http://flickr.local/ or http://flickr.api?)

Answer 1

A URL locates a resource by specifying the path of that resource and the protocol to use to access that resource. All of your examples are equally RESTful. They identify a resource relative to the REST Client that the REST Client wants to access.

The REST client is free to specify the location of the resource he wants to access. The REST Client should have the knowledge to know that the api.local server contains or does not contain the resource he wants to access.

If it is your REST server's intent to have a universally accessible resource, then you should respond with resource not found unless it is asking for the correct URL.

It is perfectly acceptable that you have a situation where you have a REST server on the local machine and another one on the Internet. The REST Client will specify whichever ever one he wants to access.

That being said it is not the best design to have many different URLs referring to the same resource. So there's nothing wrong with using api.local but it's better to allow such things when api.local and api refer to different resources.

Answer 2

URL stands for "Uniform Resource Locator", not "Universal Resource Locator". There's nothing implied in URL that says it should be "globally" or "universally" accessible. So I don't see a problem with *.local for local testing (it would certainly seem bad to me to have a test or development environment that was accessible from anywhere).

Answer 3

One of the main practical issues behind the "only one URL should return a resource" is because of the effect on caches. If you have two URLs for the same resource then you can end up with two copies in the cache. If you do a PUT to one of them, then the cache should invalidate both, but it does not know about the relation between the two copies.

Regarding the issue where you are using a hostname that may resolve to different stream of bytes depending on where you dereference it from, I don't see that as a problem at all. Conceptually you are accessing the same resource, it is really just a different instance of that resource. I use this extensively as a form of discovery mechanism. I develop an enterprise application that is hosted on a server that I alias as "TMServer". Within an organization, there is only ever one instance of a TMServer and all resources are accessed from that host. e.g. http://TMServer/Suppliers At one of my other customers, that same URL would resolve to a completely different set of suppliers but it is still conceptually a "list of suppliers".

If one of my customers were to try and share an URL with an another company, then the URL would need to be expanded to something like, http://TMServer.company.com/Suppliers. This then becomes a universally unique URI.

By using the DNS alias, I can easily use my .hosts file to redirect where TMServer points to for testing and by adding an entry in a DNS Server I can broadcast the availability of the service to all users on the network.

Answer 4

URLs aren't RESTful. Applications are RESTful (or not), but URLs aren't. In fact, in a RESTful application URLs are completely irrelevant, so the mere fact that you are worrying about whether or not your URLs are RESTful shows that your application isn't. But that doesn't have anything to do with URLs.