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).
Uniform Resource Identifier (URI): Generic Syntax [RFC3986], 2005
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.
maybe this should be added to @stilkov's REST Litmus Test for Web Frameworks.
BTW - thanks to fellow #rest channel denizens darrelmiller, cybernd, fu-manchu, and jsled for their contribution to the channel thread on URIs and resources.