[pornel]

     /search/bass/sort/artist/

That doesn't look like a hierarchical resource. You probably don't list sort options under /search/bass/sort/, and even then /search/bass/sort/artist/ wouldn't be logical subset of that.

This URL looks more like a different view on /search/bass resource, so /search/bass?sort=artist is IMHO more appropriate.

[ericmoritz]

The standard is to use / for hierarchal data and URL params to alter the resource's content. For instance:

/search/ would be an empty search, and for the sake of argument let us say that it returns the entire collection.

/search/?query=bass

This would restrict the collection to return only records that contain the word "bass". Based on the way that URLs are defined, these are considered separate resources.

The same with this URL:

/search/?query=bass&page=10

This is a different resource than the previous. In this case, sometimes it feels like the page should be a member of the search collection. It's up to you whether you prefer a URL like this

/search/pages/10?query=bass

In my head that is incorrect because to me the query string manipulates the last item in the hierarchy which is "pages/10". So the order of operations would look like this:

1. Select the first page from the search collection 2. return only items on the first page that contain the word "bass"

[_ikke_]

I would say it would be a different (limited) representation of the same resource.

[colin_jack]

In HTTP resources are the things identified by the URL, so if you change the query parameters you are addressing a different resource.