[ part of this exchange happened off list, replying to list] On Dec 18, 2007 6:55 PM, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > > On 19/12/2007, at 11:41 AM, Hugh Winkler wrote: > > > On Dec 18, 2007 5:48 PM, Mark Nottingham <[EMAIL PROTECTED]> wrote: > >> > >> On 19/12/2007, at 10:38 AM, Hugh Winkler wrote: > >>>> 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. > >> > >> As does it here, using the hints in fq:interface. Admittedly, it's a > >> pretty constrained set of hints, but so are HTML forms, really. > > > > Hrrm. I hadn't picked up the forms-like nature of fq:interface > > > >>>>> 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. > >> > >> Right, but then it has to remember the Location that it gets back, > >> and > >> remember to fetch it in the future. I get a certain amount of > >> resistance to this when I suggest this to devs. *shrug* > > > > They don't have to do that if they don't want to. They can just POST > > the entity each time and consume the response. That's no more trouble > > than doing GET, and in most cases no less efficient since the '?' > > suppresses many caches. > > But the point is to enable caching... >
Right. Well the most cacheable way is POST + 303. Then the devs do have to record the Location header. But GET url + '?' + query string won't cache much of the time. Maybe that's getting better, and I'm sure you're more up to date with the state of the art. But my pretty recent Squid doesn't do it out of the box. > > >> In any case, I'm happy expanding section 4 to include the POST case, > >> and defining a media type. > >> > >>>> 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. > > > > not sure I feel so strongly about this that I'd want to muddy the > > waters with alternatives. Let's see if there's any traction. > > > > (btw you replied off-list) > > Oops, sorry, feel free to forward. > > > > >>> Heck, Mark, I even threw in a cacheability argument ;) > >> > >> You nearly had me :) > > > -- > Mark Nottingham http://www.mnot.net/ > > Hugh
