Subject: [apps-discuss] Standardising Structure in URIs: one more anti-pattern

From: Erik Wilde <[email-masked]>
Date: Mon, 04 Nov 2013 11:21:18 -0800

hello.

following up the conversation in today's APP meeting: it seems that the 
goal for this document might remain to focus on what shouldn't be done, 
as opposed to also provide comprehensive guidance on what to actually 
do. i think that's a good direction, and as tim bray pointed out, maybe 
getting the "you shouldn't be doing this" could be a very good 
motivation and starting point to start with "and here's what you should 
do" in a variety of areas.

here's one pattern that could be added to the current draft: there are 
various services that depend on clients adding "URI parameters" to a 
URI, often by simply appending a string. this amounts to clients 
"generating URIs" based on scenarios that often assume that there's some 
way in which those parameters are "tunneled" through services (and get 
ignored if servers don't support the parameter). this assumes that (a) 
URI parameters can be reliably parsed, instead of (as the current draft 
mentions) accepting the fact that URI parameters are neither defined by 
the URI, nor by the HTTP spec. it also assumes that a request to 
http://example.com/resource can also be sent to 
http://example.com/resource&par=value, and things will still work (which 
they may, but things may also break, depending on how requests are being 
handled by the server). maybe adding the anti-pattern to the draft might 
be useful?

ideally, i'd like to see as many of these typical anti-patterns in the 
draft as possible. if people propose them, it should be possible to 
simply link to http://tools.ietf.org/html/rfc7xxx#section-3.xxx that 
will describe the anti-pattern, and explains why it's a bad idea.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |