Closed huard closed 6 years ago
I started the discussion internally on Open API / Swagger. I had good interaction with people. I'll tag you on our slack, maybe we can start a channel for discussions on this.
Qui est bien connaissant sur Swagger / Open API au CRIM? @carolinemusy?
28 replies Caroline Musy [4 days ago] dans Vesta et Pacte j'ai utilisé Swagger (dans le framework Scalatra), Swagger UI et Swagger Codegen (en Java)
Tom Landry [4 days ago] on aura possiblement quelques questions pour PAVICS
Tom Landry [4 days ago] C'est un sujet très chaud, c'est en demande auprès de plusieurs autres collaborateurs
Sanni Farooq [4 days ago] @stephane
stephane [4 days ago] on a utilisé flasgger(python) et swagger-combined(node.js) pour la VDM.
Fred Osterrath [4 days ago] Faudrait que je me mette à flasgger. (Serait bling d'avoir cela sur le SG)
Tom Landry [4 days ago] Hot topic. Est-ce que c'est matière à Lunch and Learn?
Tom Landry [4 days ago] Moi j'y connais pratiquement rien, mais quand t'entends ça dans 3 communautés différentes, c'est le temps d'agir
Fred Osterrath [4 days ago] Bof, à mon avis c'est de la matière à je prends 2 heures sur une journée pluvieuse à gosser ça mais c'est vrai qu'on peut en discuter pour faire le tour des trucs et astuces, comparaisons à des paradigmes WSDL et cie ...
Tom Landry [4 days ago] Bien mon point d'action c'est de récupérer les use case Swagger des communautés en question (ESGF, OGC, PAVICS-Birdhouse)
Tom Landry [4 days ago] Puis voir si "le CRIM" sait résoudre le problème, ou si on a des solutions deja prêtes
Jean-François Héon [4 days ago] Lesson learned de RACS: notre framework web étant Tornado, on n’avait pas des lib de génération de code à partir du swagger contrairement à si l’on aurait utilisé Flask. Le swagger du RACS et utilisé pour documention et pour interop avec le backend qui genere du Scala avec le fichier Swagger. Bref, c’est arrivé de produire un fichier swagger qui semblait correct mais qui était incorrect alors on ne s’en rendait compte qu’à l’intégration. (edited)
Tom Landry [4 days ago] J'ai le gout de mettre un pouce aussi, mais je suis un peu fatigué et je comprends pas toute
Renaud Hébert-Legault [4 days ago] Dans PAVICS même, les deux APIs REST sont documentées avec Swagger à savoir Magpie (sur swaggerhub) et Project-api (auto-générée par loopback.io) (edited)
Tom Landry [4 days ago] Cool, en gros l'idée pour Birdhouse (pas OGC ou ESGF) serait de voir si Swagger peut nous aider à générer des APIs pour les services WPS
Renaud Hébert-Legault [4 days ago] à ma connaissance Swagger est essentiellement RESTful et WPS 1.0 ne l'est pas
Fred Osterrath [4 days ago] Hmmm, ouains. C'est vrai qu'il pourrait y avoir un mismatch dans la façon de décrire certains éléments, mais est-ce que ça empêcherait totalement de décrire à l'aide de Swagger un API WPS ?
Fred Osterrath [4 days ago] Par ailleurs, il faut se poser la question : Qu'est ce que ça offre de plus que getCapabilities et est-ce que cette valeur ajoutée est véritablement souhaitable.
Tom Landry [4 days ago] De façon générale, je crois que OGC est à l'aise à faire avancer la standardisation des interfaces géo avec OpenAPI
Tom Landry [4 days ago] Si ca améliore l'interopérabilité, c'est bon.
Tom Landry [4 days ago] J'ai cru remarquer aussi que Swagger était utilisé par les participants OGC... well pour définir des APIs bien spécifiques first. Comme le billing pour les webservices par exemple.
Tom Landry [4 days ago] Puis en un deuxièment temps le mapping vers le call processus (WPS) se fait.
Tom Landry [4 days ago] Si Swagger facilite l'écriture du GetCapabilities des process en dessous (WPS), c'est bénéfique
Renaud Hébert-Legault [4 days ago] J'avoue que Swagger Inspector a l'air intéressant pour ce genre de besoin (généré une définition OpenAPI)
Tom Landry [4 days ago] http://docs.opengeospatial.org/wp/16-019r4/16-019r4.html
Tom Landry [4 days ago] OGC® Open Geospatial APIs - White Paper
@osterrfr-crim The rationale for this is to reduce the friction to reach users. Imagine you teach a class using Jupyter, and you want your students to use some piece of code that runs on a WPS server. You don't need them to learn what WPS is, or even care where the code runs. You just want them to import a library, look at the functions within them and call them as if they were native objects. The only difference is that they would run asynchronously. All the low level stuff (server URL, getCapabilities, describeProcess, execute) would be used by the wps-client-generator to write the library. We can probably do this using just owslib, but that would only cover Python. My question is whether or not it is possible to use swagger to automatically create thin clients for a number of languages (Matlab, R, etc).
So development would look like:
Birdy is providing automatically a WPS as a command-line interface (using OWSLib). It is probably not much effort to use Birdy to provide WPS "functions" as Python library. But, yes, it would be Python only.
Just for the confusion :) There is also XML-RPC to provide "remote procedure calls" and can be called by several xml-rpc clients in different languages. XML-RPC is quite old, there is also a version working with JSON instead of XML.
I think starting with birdy is a great idea. We could see later if we can find a general purpose solution for other languages.
See https://github.com/bird-house/birdy/tree/thin_client for a first preliminary implementation. Tested only on a basic process, no authentication, no remote file retrieval, ... @cehbrecht You're probably best placed to add all the stuff from your cmdline module.
Using the content of getCapabilities and describeProcess, create a thin python client based on owslib to launch async processes as if it was a native python library.
Discuss with Markus Neteler.