URIs and Resources

2010-07-06 @ 14:57#

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.

Roy T. Fielding on REST-Discuss, 2002

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.