Comment by chewxy | Hacker News Reader

Comment by chewxy | Hacker News Reader

I understand the need for a nice URL, perhaps indicative of RESTfulness, but I see a few problems with this:

1. From a REST point of view - the map is the resource. The adddress is well, not really a resource (the logic goes like this: if the address is the resource, the browser as a resource getter should only get the address, not the surrounds). IMHO the address should be modelled as an element of the resource, accessible by Maps' javascript.

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.

For example:

Tokyo-to (city), Taito-ku (ward), Yanagibashi (neighborhood) 2 (area)-20 (block)-2 (building) 602 (room number)

It would fit into the proposed URL scheme perfectly: Tokyo/Taito/Yanagibashi/2/20/2/602

"a nice URL, perhaps indicative of RESTfulness"

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.

Well said.

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.

Agreed and well said. Nice URLs do not have to be RESTful, but RESTful URLs have to be nice. Personally, its just OK for me if the entire URL looks like:

maps.google.com/whatever-nice-text-describing-location?ll=lat,long

If the lat/long is missing, then ask Maps to do a search. If its present, then its just a "nice" URL. Not necessarily RESTful.

Edit: Formatting

> RESTful URLs have to be nice

Not by any meaningful definition of REST.

> (the logic goes like this: if the address is the resource, the browser as a resource getter should only get the address, not the surrounds).

The browser doesn't retrieve the resource, it returns a representation of the resource. A map centered on a location is a valid representation of a resource identified by an address.

Reply on news.ycombinator.com