4 ms·

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 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.

matryer 13y ago
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 http://github.com/stretchr/thru) that doesn't do any routing or path parsing etc.
- NathanKP 13y ago
  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.
paultannenbaum 13y ago
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.
- NathanKP 13y ago
  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.
  - matryer 13y ago
    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.
- matryer 13y ago
  URL parameters ARE RESTful and I agree that your use case is exactly where parameters are useful.
matryer 13y ago
... I do like the 'routing all paths to one page' idea though.
yogo 13y ago
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 :)

matryer 13y ago

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 http://github.com/stretchr/thru) that doesn't do any routing or path parsing etc.

NathanKP 13y ago
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.

paultannenbaum 13y ago

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.

NathanKP 13y ago
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.
- matryer 13y ago
  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.
matryer 13y ago
URL parameters ARE RESTful and I agree that your use case is exactly where parameters are useful.

matryer 13y ago

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

yogo 13y ago

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 :)