DALIInterface/TAPRegExt evolution

[Patrick Dowler]

A few things I have been thinking about that are related to this

1. We have been working to prototype doing all the authentication related
stuff with http headers (WWW-Authenticate etc) and that alternate approach
looks to be in good shape

2. The other ivoa service standard with multiple (some optional) endpoints
is VOSpace so I think we'll ultimately want a solution that isn't
DAL-specific

The other thing that has been nagging at me is that in each service we
implement, we have a machine-readable VOSI-capabilities doc (and we use
this extensively in our client-service and service-service interactions)
*and* I have a human-readable API document.... the latter is currently
using something called swagger which is a javascript client that reads a
different machine readable description of the service (based on or close to
Open API). I'd really like to have one such document that describes the
available API.

And this smaller tidbits that I'll look for in the doc:

3. I have been running into various scenarios where I have a REST API for
some endpoint, some implementations support all the actions (http HEAD,
GET, POST, PUT, DELETE) and other implementations only support a subset
(usually, that's http HEAD and GET because this is a read-only service)...
would like to work on a solution to this and can provide use cases

4. I have also run into a scenario where an endpoint has one primary API
(capability standardID="foo") but also supports another API. In this case,
this is a service in front of a storage system and the service supports a
"files API" (HEAD, GET, POST, PUT, DELETE) and some implementations also
support the SODA API (optional params to do operations). So that's an
endpoint with two standardID values in the capability? Something to think
about... this one crosses paths with #3 above because we have some
implementations that support read-only "files API" (HEAD, GET) plus SODA.

Anyway, thanks Markus - I will review and comment.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 22 Sept 2021 at 07:36, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DAL,
>
> When we tried to work out how to deal with authentication in the
> Registry, it turned out that our conventional way of registering
> complex, multi-endpoint services had a few rather severe problems,
> which I discussed in the Caproles Note
> (http://ivoa.net/documents/caproles/).  Among our current standards,
> this mainly concerns TAP, and more concretely, its rules for the
> Registry, TAPRegExt.
>
> As a proposal for how to evolve TAPRegExt to address Caproles, I've
> just created PR#5 against TAPRegExt, which you're welcome to review;
> a pre-built rendering is at http://docs.g-vo.org/TAPRegExt.pdf.
>
> As I'm writing in the PR comment, I'd say we should iron out any very
> rough edges in the PR but then try for a WD even if people don't feel
> entirely comfortable with the proposal in order to keep at least a
> bit of that discussion on the mailing lists (as opposed to github
> discussions).
>
> That would mean that at this point hard-core TAP enthusiasts would be
> invited to review and comment.  The wider community probably can wait
> until a WD is out; the whole thing can, I expect, still be shot down
> then.
>
>         -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20210922/a1f76039/attachment.html>