IMO we have not discussed GET vs POST vs PUT, but I agree with Jeff that putting the query string (URLEncoded) in a GET url will likely be problematic. Specifically, there is a limit to the length of a URL and you may not be able to tell in practice (on the server side) that you passed it and suffered truncation. Sure the client might check the length, but then what?
It seems to me that http POST is the next likely candidate (depending on the flavour of REST religion we may or may not adopt :) I like the idea of POST because it still allows for something simple like a page in a browser to submit a TAP query and doesn't limit what a more capable client might do.
my 2c,
Pat
On Friday 18 May 2007 15:19, Doug Tody wrote:
> To clarify, what I meant in my closing plenary comment was that
> I think what we agreed was to eliminate the use of parameters for
> query restriction (hence no POS,SIZE,BAND, no range-list constraints,
> etc.) but not the use of the basic HTTP GET parameter mechanism
> where we might have other general non-query constraint params such
> as REQUEST, VERSION, FORMAT, QUERY=<adql-string>, or whatever, which
> do not duplicate functionality found in the ADQL but which are needed
> to compose a GET/POST operation. - Doug
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2007-05-18Z14:20:32