I understand the need for a nice URL, perhaps indicative of RESTfulness, but I see a few problems with this:
2. Of course you can have nice URLs without being indicative of RESTfulness. Consider an address in Japan. They do not have road names, instead, they use building/block numbers for naming/addressing. While that can still be modelled as a nice URL, the convention is now flipped, and people will be confused
3. Consider that some places do not actually have an address. Like my former residence. Due to changes in the roads, my place had a new road with no name, and no actual address (well, eventually it did, and the road still has no name. Getting pizza delivered was tough)
What can be done of course is a bit.ly kind of thing, which I think will work. Something like /maps/199-valencia-street-san-francisco-california-united-states. The current google maps url is already kinda like that (with ?q I believe)
> Consider an address in Japan. They do not have road names, instead, they use building/block numbers for naming/addressing. While that can still be modelled as a nice URL, the convention is now flipped, and people will be confused
It's not flipped at all. Japanese addresses go big -> small, just like the URL. As a matter of fact, the US addresses are flipped since US addresses go the other way.
My understanding is that "nice URLs" and "RESTfulness" are orthogonal. Difference implementations of the same RESTful interface could have completely different URL formats and they should all be compatible with clients written to the interface specification.
Having said that, best to have nice URLs and RESTfulness.
It's in some ways quite anti-RESTful for a consuming client to start to try parsing a URL semantically. "URL building" is not something a client should be responsible for, it should be (semi-)blindly using URLs the service has provided for it.