DALIInterface/TAPRegExt evolution

[Markus Demleitner]

Hi Pat,

On Wed, Sep 22, 2021 at 09:32:13AM -0700, Patrick Dowler wrote:
> 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

That's true, but I'd say an extra standard that defines this
interface class is a lot of paperwork for no tangible benefit.  
I'd hence still propose that, if we go this way, DALIInterface ought
to migrate into DALI after it has matured in TAPRegExt.  I don't
think there's any harm in VOSpace taking it from there.

On the other hand, yes, where there are additional requirements or
constraints from VOSpace, I'd say they are valid points in the
present discussion.

> 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.

I'm not so terribly convinced that for VO services, it is terribly
helpful to have some documentation at each service -- in the end,
the standard with a lot more comprehensive API docs is just a click
on http://ivoa.net/Documents away.

Having said that, DaCHS comes with an XSLT for VOSI capabilities that
makes it look like, for instance, this in web browsers:

http://dc.g-vo.org/feros/q/ssa/capabilities

I'd hope that with a bit more love and perhaps some strategic fixes to
VOResource this could come rather close to what I think you're after.

> 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

This sounds like what I'd call "custom" services.  There may be a
place for these in the Registry, in particular if there are some
conventions for such custom services that clients can use to still
operate them without or with very little human intervention.

However, I'd submit that's something we shouldn't overload
DALIInterface with; it sounds more like something for a registry
extension of its own (which can, if you want, again physically sit in
DALI; I'm just saying that we shouldn't encumber DALIInterface
considerations with that).

> 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.

I'm fairly sure that we should model this situation as two
capabilities.  I'd be surprised if these shared very much in terms of
their metadata except for the access URL.

       -- Markus