<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Russ, all,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 20 feb 2024 alle ore 19:33 Russ Allbery <<a href="mailto:eagle@eyrie.org">eagle@eyrie.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have added a starting point for looking at an OpenAPI schema for Simple<br>
Cone Search. README is available at:<br>
<br>
<a href="https://github.com/ivoa/PTTT/tree/main/cone-search" rel="noreferrer" target="_blank">https://github.com/ivoa/PTTT/tree/main/cone-search</a><br>
<br>
This is mostly a framework to get started and let us quickly iterate on<br>
the OpenAPI schema by letting FastAPI do most of the work. I focused on<br>
getting the framework in place rather than adding a lot of API details.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Thanks for setting this up.</div><div class="gmail_default" style="font-family:monospace">I'm no expert on these technologies, I suppose it</div><div class="gmail_default" style="font-family:monospace">would be useful to overview all of this at the next</div><div class="gmail_default" style="font-family:monospace">vconf (Monday), at least as a start for people like me.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This provides only a sync GET interface without capabilities or<br>
availability. For a more fully-fleshed example, we'll want to add an async<br>
interface with UWS and models for capabilities and availability. I plan on<br>
working on that next if this is a suitable starting point.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">I wonder if it's better to stick to the current</div><div class="gmail_default" style="font-family:monospace">ConeSearch-1.03, which has no POST.</div><div class="gmail_default" style="font-family:monospace">I'd like this discussed too.</div></div><div> </div><div><div class="gmail_default" style="font-family:monospace">All the rest is wonderful.</div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace"> Marco</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some additional notes and cautions:<br>
<br>
* FastAPI is not an ideal OpenAPI schema generator, and I suspect it will<br>
not generate exactly the schema that we would want. Please consider this<br>
only a proof-of-concept for fast iteration. An OpenAPI schema suitable<br>
for publication would likely require some additional manual tweaking.<br>
<br>
* FastAPI makes documentation available with both Swagger and Redoc. Both<br>
of them have their quirks, but they're both useful renderers for human<br>
browsing. I personally prefer Redoc, but I encourage folks to try<br>
both. Swagger has a bug that causes it to double-escape the example<br>
VOTable response. This appears to be rendered correctly in Redoc.<br>
<br>
* Apologies for the giant blob of XML that's awkwardly encoded in the JSON<br>
file. I wanted to show how XML responses can be documented, but the<br>
resulting JSON is pretty ugly.<br>
<br>
* The error model is a quick hack based on the errors that FastAPI<br>
produces by default, including the 422 error code that FastAPI likes to<br>
use for requests that fail schema validation. This is probably not the<br>
exact error model that we want. I threw it in there so that people could<br>
see how we could define structured errors, not to propose this specific<br>
structured error format as the best one (although it is convenient in<br>
Python since FastAPI generates it by default). We will probably also<br>
want to document some additional error codes (at least 401 and 403).<br>
<br>
Let me know if you have any comments, questions, or problems following the<br>
README.<br>
<br>
-- <br>
Russ Allbery (<a href="mailto:eagle@eyrie.org" target="_blank">eagle@eyrie.org</a>) <<a href="https://www.eyrie.org/~eagle/" rel="noreferrer" target="_blank">https://www.eyrie.org/~eagle/</a>><br>
-- <br>
p3t mailing list<br>
<a href="mailto:p3t@ivoa.net" target="_blank">p3t@ivoa.net</a><br>
<a href="http://mail.ivoa.net/mailman/listinfo/p3t" rel="noreferrer" target="_blank">http://mail.ivoa.net/mailman/listinfo/p3t</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 [also Telegram]</span><br></div></div></div></div></div></div></div>