TAP RFC [VOSI]

[Doug Tody]

On Mon, 28 Sep 2009, Patrick Dowler wrote:

> Just to clarify:
> 
> I take it that with this compromise resources and service ops
> (getCapabilities) would both be required in TAP 1.0, with a very
> simple explanation that they return the same document. Thus, the sync
> endpoint would retain the DAL RPC style interface and the users of
> either endpoint could use the resources or the RPC mechanism in 1.0.

Yes, this is the proposal.  Both should be provided and should be
mandatory.

> It would open up the possibility in future to make one or both of
> async and sync optional. Just looking ahead to that a bit, it seems
> one would likely do it as follows:
> 
> - async is optional
> - if async is supported, async must have sibling resources for metadata
> - sync is optional
> - if sync is supported, sync must support service ops

In practice I think this would want to be specified separately for
each interface.  For example while either sync/async might be optional
for TAP, a sync QueryData operation might be mandatory for SIA/SSA.

> It appears we could make such a change without making any TAP 1.0
> services invalid. Thus, we have two usage patterns that mesh together
> and we just have to make it clear that these few things that look like
> the same thing really are and they return the same metadata documents.
> 
> We retain the REQUEST and VERSION (it was retained in the proposed
> change, maybe that was not clear) as an avenue for future evolution
> or as a way for services to do custom operations.

REQUEST and VERSION would be retained, and would be the standard
way to specify logical service operations (operations with params)
using the sync/async resources.  Hence we can have any number of such
operations sharing the same basic service mechanism, including both
standard operations as well as custom operations added by a given
service implementation.

As you say this gives us a nice way to mesh the two usage patterns.
Some services might take the OO/RPC approach using REQUEST/VERSION,
but others could take the REST approach, depending upon which model
is more appropriate for the problem being addressed.

 	- Doug


> Does that capture the essence of the proposed compromise? Does anyone
> see any issues or dead-ends for later versions?
> 
> Pat
> 
> PS-I don't know that we will ever want to make sync/async
> optional... but I will comment in response to Alberto's question in
> a separate message.
> 
>
>  On Sunday 27 September 2009 10:11:22 Douglas Tody wrote:
> >      1)  We add resource endpoints for the VOSI operations.  Hence for base
> >          resources we have the following (all with the same baseURL):
> >
> >              sync
> >              async
> >              capabilities
> >              availability
> >              tableMetadata
> >
> >      2)  We retain REQUEST and VERSION to specify the logical (service
> >          specific) service operations.  These use either the sync or
> >          async endpoints.  Hence we have
> >
> >              async/REQUEST=doQuery&VERSION=1.0&...       # TAP
> >              sync/REQUEST=queryData&VERSION=1.0&...      # Other DAL
> >                  (etc.)
> >
> >      3)  We require that getCapabilities be provided as a service
> >          operation as well as as a base resource:
> >
> >              sync/REQUEST=getCapabilities
> >
> 
>