Comment by NathanKP | Hacker News Reader

Comment by NathanKP | Hacker News Reader

The library looks very nicely done, however, personally I think it is better to avoid such query string parameter formats completely. So to use an example from the Github page:

     http://www.stretchr.com/?name=Mat&company=Stretchr#?comment=123

should become

     http://www.stretchr.com/companies/Stretchr/users/Mat/comments/123

The URL now looks much nicer and more readable, and it also leads to organized hierarchy because of predictable URL patterns. So maybe the user wants to see the list of all users in the Stretchr company. So just from the URL they can determine that a good way to do that is probably by removing the end of the URL so that it is:

     http://www.stretchr.com/companies/Stretchr/users

Anyway, that's just my personal preference, but I think that query string style URL's should be avoided unless absolutely necessary and nicer REST style URL's should be used instead.

If you have a one page app you can route all requests on the domain to one page, and then use Backbone logic to look at the REST style URL and show the correct view based on the URL.

My preference would be the clean, hierarchical view but there are a few filter-type scenarios where the order isn't known ahead of time or matter at all. For example a user might want to view a/b then append c/d (a/b/c/d) or vice versa (c/d/a/b). It is possible to make this with clean url but it seems like a bit more work since you might need more logic as far as parsing and routing.

Edit: pretty cool how all the sibling comments are along the same lines :)

I love that style too actually - and always prefer it when I can. Sometimes, you just need parameters.

But more and more I'm writing apps with no backend (Stretchr makes it easy to do so) in just HTML5 and JavaScript... and serving pages like that tends to be more difficult.

I use a simple web server (like Thru http://github.com/stretchr/thru) that doesn't do any routing or path parsing etc.

Nice. I'm a big fan of little to no backend as well. I've done a similar simple web server in Node.js which does nothing but check to see if a static file exists to serve the request. If so it serves that static file. If not then it serves the index.html page. The index.html page then has Backbone logic to parse the URL and serve a proper view based on what the URL is. It matches up nicely with the REST style URL's and you still don't need a heavy backend to do routing that way.

I agree if everything in your app follows a perfectly restful pattern, but what about if you want to capture application state that does not belong in a database. For example, what if you have an online store that has many different filters to narrow down selections. And you want to share this url with someone.

How would this be done using a RESTful url path? You have to use url params. If so, this seems to be a nice solution if your using a lot of params.

Here is how I would do it:

Assuming you were searching for computers with the following filters:

    Manufacturer: Apple
    Type: Laptop

You could represent that as:

     http://mystore.com/electronics/computers/manufacturer/apple/type/laptop

If you make your routing code (on either the frontend or the backend) robust enough then you will be able to support any number of filters in any order.

for nested data - I 100% agree. I'd do that and use params for things like ordering or filtering on other fields:

    http://mystore.com/electronics/computers/manufacturer/apple/type/laptop#?order=-price&size=medium

Also - the `#` is nice for when you don't want to reload the page.

URL parameters ARE RESTful and I agree that your use case is exactly where parameters are useful.

... I do like the 'routing all paths to one page' idea though.

Reply on news.ycombinator.com