The resource is the whole string between the domain and the fragment identifier. '/' is no different from '?' or '&' — it's all the same once you drop your false-REST preconceptions.
The HTML spec does define a standard for concatenating the name-value pairs from form elements onto target attributes for use in GET requests, but that doesn't reify it into the definition of HTTP, much less the definition of REST.
Except the use of parameters for resource identification both breaks REST and isn't SEO-friendly. Forms somewhat break this for GET submissions, but do at least adhere for POST.
Comments
All of your examples still portray uniformity:
> git://github.com/thoughtbot/paperclip.git
You are accessing a resource that is partially identified by the username.
> smtp://user:pass@hostname/domain
The username and password is used for authentication to access the resource, but is part of its unique identification.
> http://news.ycombinator.com/user?id=krainboltgreene
The mistake actually lies with HN, because part of what should be used to identify the resource is instead a param.
> chrome://history/
This still fits because you are accessing a uniquely identified resource. Just because it is user-dependent does not mean it breaks REST.
URL Parameters ≠ RPC
The resource is the whole string between the domain and the fragment identifier. '/' is no different from '?' or '&' — it's all the same once you drop your false-REST preconceptions.
The HTML spec does define a standard for concatenating the name-value pairs from form elements onto target attributes for use in GET requests, but that doesn't reify it into the definition of HTTP, much less the definition of REST.
Except the use of parameters for resource identification both breaks REST and isn't SEO-friendly. Forms somewhat break this for GET submissions, but do at least adhere for POST.