TAP parameter=value issue
guyrixon at gmail.com
Sun May 20 07:17:38 PDT 2007
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.
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
> 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
> We already use URL encoding in VO, for example, one cannot pass an
> identifier containing the "#" character in a GET unless it is URL
> - 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
>> 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
>>> 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
>>> to compose a GET/POST operation. - Doug
>> As an aside, I've been an interested spectator of the meta data
>> I'm still not sure what to make of it overall. But it does seem
>> that we could end up with a number of ways of obtaining meta data:
>> 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.
>> 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
More information about the voql