Fragment identifiers are currently the only part of a URI that can be changed without causing a browser to refresh the page
This is actually the primary reason for most of the hash and hash-bang uris in today's javascript-heavy sites. Once all the popular browsers allow changing URI without reloading the page, the whole issue will become irrelevant.
I am actually a big fan of HTTP and REST (the real one, with HATEOAS), but browsers have a long history of making it hard to write RESTful web sites. HTTP methods had long been restricted to GET/POST; code-on-demand support before XHR had been very rudimentary (javascript was almost useless, and I don't even want to mention java applets); browser addressing conventions led to horrible (from the REST point of view) practices like redirect-after-POST etc.
This is actually the primary reason for most of the hash and hash-bang uris in today's javascript-heavy sites. Once all the popular browsers allow changing URI without reloading the page, the whole issue will become irrelevant.
I am actually a big fan of HTTP and REST (the real one, with HATEOAS), but browsers have a long history of making it hard to write RESTful web sites. HTTP methods had long been restricted to GET/POST; code-on-demand support before XHR had been very rudimentary (javascript was almost useless, and I don't even want to mention java applets); browser addressing conventions led to horrible (from the REST point of view) practices like redirect-after-POST etc.