On Dec 18, 2007 5:26 PM, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > On 19/12/2007, at 10:14 AM, Hugh Winkler wrote: > > > > I'm uncomfortable with prescribing how to construct URIs (sec. 4), > > aren't you? > > Why? HTML forms does it, and they're pretty successful. >
Sure. But the server implementer has control over the eventual constructed URL. The server can even send javascript down and construct an URL without a query part. Either way, using HTML form or javascript, the server provides the code that constructs the URL. > > It takes control of the URI namespace away from the > > server. > > Just as with forms, this only specifies a format that's meaningful if > the server chooses to use it; it doesn't foist itself upon the URL. > Not sure I understand what you're saying here. Looked to me like you contemplate clients sending GETs to URLs they construct without any guidance from the server? > > You can get the effect you want by POSTing an entity > > containing the FIQL string (give it mime type application/fiql say) > > and allowing the server to respond directly with the result, or return > > 303 to the URI of a cacheable representation. Let the server construct > > the URI. > > POSTing a query works, but for whatever reason, people don't like the > added step. What extra step? the client just sends the FIQL string as an entity in a POST rather than tacking it to the URL of a GET. >The draft doesn't rule that out, of course, but most > people will want to put it in a URI; it's up to the server to decide > how it wants to do it. It would make sense to define a media type for > a FIQL query if people want to do this, though; I'll add that to the > next draft. > Heck, Mark, I even threw in a cacheability argument ;) > Cheers, > > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Hugh Winkler, CEO Wellstorm Development http://www.wellstorm.com/ +1 512 694 4795 mobile (preferred) +1 512 264 3998 office
