<div dir="ltr"><div class="gmail_default" style="font-size:small">A few things I have been thinking about that are related to this</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And this smaller tidbits that I'll look for in the doc: <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Anyway, thanks Markus - I will review and comment.</div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 22 Sept 2021 at 07:36, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DAL,<br>
<br>
When we tried to work out how to deal with authentication in the<br>
Registry, it turned out that our conventional way of registering<br>
complex, multi-endpoint services had a few rather severe problems,<br>
which I discussed in the Caproles Note<br>
(<a href="http://ivoa.net/documents/caproles/" rel="noreferrer" target="_blank">http://ivoa.net/documents/caproles/</a>). Among our current standards,<br>
this mainly concerns TAP, and more concretely, its rules for the<br>
Registry, TAPRegExt.<br>
<br>
As a proposal for how to evolve TAPRegExt to address Caproles, I've<br>
just created PR#5 against TAPRegExt, which you're welcome to review;<br>
a pre-built rendering is at <a href="http://docs.g-vo.org/TAPRegExt.pdf" rel="noreferrer" target="_blank">http://docs.g-vo.org/TAPRegExt.pdf</a>.<br>
<br>
As I'm writing in the PR comment, I'd say we should iron out any very<br>
rough edges in the PR but then try for a WD even if people don't feel<br>
entirely comfortable with the proposal in order to keep at least a<br>
bit of that discussion on the mailing lists (as opposed to github<br>
discussions). <br>
<br>
That would mean that at this point hard-core TAP enthusiasts would be<br>
invited to review and comment. The wider community probably can wait<br>
until a WD is out; the whole thing can, I expect, still be shot down<br>
then.<br>
<br>
-- Markus<br>
</blockquote></div>