On Wed, Feb 10, 2021 at 1:58 AM Gabriel Roldan <gabriel.rol...@gmail.com> wrote:
> First and foremost, I am generating a Java client from the OpenAPI > documents. Not the swagger 2 ones provided as documentation, but OAS3 ones > created using those as reference. > > Here's a project I just made public a couple of days ago: > https://github.com/camptocamp/geoserver-rest-openapi > > At camptocamp we're using it in production for over a year in an internal > project, but now I moved it as a standalone project to be used by the OSS > project geOrchestra. > > It only implements the minimum I needed for that internal project so far. > That is, working with workspaces, datastores, feature types, layers, and > styles. And probably not even all of it. > > Also, it focuses on JSON representation only. > Nice to see a Java based client, geoserver-manager died several years ago leaving no replacement as a Java based GeoServer REST client. If enough people are interested, and it lives long enough, no doubt it will eventually cover fully functionality, or close to. > That said, writing the OAS3 files and the generated client wrapper code is > hard, often having to debug GeoServer itself to figure out what's going on > in the server to be able of mimicking it on the api definition. There are > several inconsistencies, not only in the outdated/incomplete swagger2 > files, but in the server itself, most of which I think are due to using > XStream to generate the JSON representations, like a single object instead > of an array when an array is expected but the result contains a single > element, excessive wrapping of objects, and several other annoyances I > didn't care to document properly at the time, but believe me, I thought > having a working set of OAS3 specs would be a nice first step towards > defining a v2 api with clearly defined api contracts and code-generated > server stubs. > Yes, we are painfully aware of all the above. > Achieving that would of course require significant resources so it most > probably will die in the wish-list. > Indeed, a fresh start for REST services would require solid funding and a new dedicated maintainer for it. The existing REST API needs close to no maintenance, besides the bug fixing and new functionality, which are both directly funded, when happening, Also the existing clients are working good enough for many, so the two REST APIs would need to be kept alive for a few years, giving existing deployers time to migrate. That's the main crux of all this discussion, there is a big chasm between those that like different, newer, cleaner functionality, but have nothing to offer in terms of funds or development time, and those that are trying to keep the project alive, already fully busy with paid work against the project, and already having a working solution for the issue at hand. I see kind of the same issue happening down in OGC API modules, they are moving one testbed or code sprint at a time, but there is very little business around them (mostly research projects), cause they are providing a different solution to a problem that was solved already 20 years ago, and for which many have working clients. Those that don't are clamoring for the new API, sure, but also providing no resources to make the modules go up and graduate. I'm just glad despite all the noise, we are managing to keep the project alive and going, pruning dead branches and moving on, instead of living the current situation in GDAL, where the project maintainer seems to have had enough of all the external requests and pressure, and disappeared from both the mailing list and twitter (I surely hope it's just a vacation.... we'll see). Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
