TAP parameter=value issue

[Guy Rixon]

Doug,

POST is only parametric if you use the same MIME-type as an HTML form  
would produce. If you define the resource to accept a POST of a  
different MIME-type then you can POST anything matching that type.  
For example, we could define a query service to which one posts a  
text/plain representation of a query and define in the spec that that  
text should be ADQL. Or we could define a special MIME-type for ADQL  
and POST that.

Cheers,
Guy

On 18 May 2007, at 13:36, Doug Tody wrote:

> Hi Jeff -
>
> Both GET and POST are parameter-based so the encoding issue is
> only partially relevant to the issue under discussion here, which
> was use of data model-based parameter queries in TAP (the point of
> the decision was that TAP should implement only ADQL-based queries,
> as opposed to DM-based constructs like POS,SIZE or RA,DEC,SR).
>
> But anyway, there actually is a standard way to include complex  
> strings
> such as an ADQL expression in a GET, called URL encoding.  If an ADQL
> expression gets large enough a POST might eventually be preferable,
> but for 90% of typical simple queries a GET with URL encoding would be
> fine, and is simpler and more RESTful for a synchronous query since
> the query is idempotent.  Probably TAP should support both GET and
> POST for synchronous queries, and only POST for asynchronous queries.
> GET is preferred for idempotent (no side affect) references in HTTP
> due to the way the Web is designed, as well as for simplicity.
>
> For information on URL-encoding see for example
>
>     http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
>
> We already use URL encoding in VO, for example, one cannot pass an  
> IVOA
> identifier containing the "#" character in a GET unless it is URL  
> encoded.
>
> 	        - Doug
>
>
> On Fri, 18 May 2007, Jeff Lusted wrote:
>
>> Hi Doug!
>>
>> Unfortunately I couldn't attend Beijing, so this is just a comment on
>> your posting. And it may be entirely out of context, so apologies in
>> advance. As always, I'm willing to be proven wrong, but I don't  
>> feel an
>> ADQL query (or any variant of SQL) is suitable for an HTTP GET
>> parameter. It looks a tall order to be able to escape all the  
>> possible
>> combinations of characters that may appear, but perhaps there is a
>> library that can already do this. I don't see any problem with  
>> using it
>> in an HTTP PUT.
>>
>> On Fri, 2007-05-18 at 01:19 -0600, 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
>>>
>>
>> As an aside, I've been an interested spectator of the meta data  
>> debate.
>> I'm still not sure what to make of it overall. But it does seem  
>> alarming
>> that we could end up with a number of ways of obtaining meta data:  
>> TAP,
>> registry, ADQL query, and presumable native SQL. I'm still reeling.
>> However, I appreciate the point about empty VOTables: as far as I can
>> see it would only lend itself to columnar meta data.
>>
>> Regards
>> Jeff
>> -- 
>> Jeff Lusted               tel: +44 (0)116 252 5358
>> Astrogrid Project         mob: +44 (0)7973 492290
>> Dept Physics & Astronomy  email: jl99 at star.le.ac.uk
>> University of Leicester   web: http://www.astrogrid.org
>>
>>
>>