URLs

URL Parametrization Schemes

Parameters (semi-colon): requires either a web-server processing step, or exisiting files for all possible values.
URL Queries: writable by form submission, requires javascript to have effects on the page. Fit for web-server pre-processing pages, Javascript applications, APIs. URL encoding of special chatacters is applied by default.
URL Hash-Fragments: changes dynamically without requiring a re-submission of the request, for client-side logic, selective styling, no-script mechanisms are possible and can get advanced, styling :target, which targets the element having id equal to the current fragment. Javascript can also leverage window.onhashchange.

Cool URI don't change ― Tim Berners-Lee, 1998

URIs don't change: people change them. (...) There is a crazy notion that pages produced by scripts have to be located in a "cgibin" or "cgi" area. This is exposing the mechanism of how you run your server. You change the mechanism (even keeping the content the same ) and whoops - all your URIs change. For example, take the National Science Foundation:
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

The main page for starting to look for documents, is clearly not going to be something to trust to being there in a few years. "cgi-bin" and "oldbrowse" and ".pl" all point to bits of how-we-do-it-now. The html document itself by contrast is very much better:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Looking at this one, the pubs/1998 header is going to give any future archive service a good clue that the old 1998 document classification scheme is in progress. Though in 2098 the document numbers might look different, I can imagine this URI still being valid, and the NSF or whatever carries on the archive not being at all embarrassed about it. (...) it is the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment. (...) Effectively, when you use a topic name in a URI you are binding yourself to some classification. You may in the future prefer a different one. Then, the URI will be liable to break. (...) 1998/pics can be taken to mean for your server "what we meant in 1998 by pics", rather than "what in 1998 we did with what we now refer to as pics." (...) The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.