URIs and Resources
a thread today in the IRC #rest channel reminded me that the way toolsets treat the details of mapping URIs to Resources can color the way devs view the various components of a URI. the common thinking (due to toolset implementations) is that the path portion identifies the "resource" and that the query portion is just additional information. however, this is not correct.
the resource identifier is made up of the path and the query portion of the URI.
The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component, ... serves to identify a resource within the scope of the URI's scheme and naming authority (if any).
unfortunately, HTTP toolsets (frameworks, libraries, etc.) often fail to adhere to the rules set out in RFC3986. instead, as a matter of expediency, toolsets sometimes lead developers down the path of mapping server-side code to the "path" portion of the URI and treating the "query" portion as additional data to be inspected after the toolset has completed the code-mapping to the "path". this can result in an unnecessary explosion of public Resource Model (RM) elements and/or needlessly complex server-side code within a URI-mapped "controller" in order to sort out the possible variations presented by non-path portions of the URI.
[F]or server-constructed URI, there is no effective difference between query and path info -- both distinguish a resource.
BTW - thanks to fellow #rest channel denizens darrelmiller, cybernd, fu-manchu, and jsled for their contribution to the channel thread on URIs and resources.