Support new Geonetwork REST API (GN >= 3.2) - main CRUD methods

[eblondel]

No description provided.

[eblondel]

The following questions have been sent to the Geonetwork user list in order to better understand the Geonetwork API status:

Would it be possible to get snapshot of Geonetwork API status, as of today:

• Is the old API yet dismissed, and if yes since which version of Geonetwork?
• Is it still the new API in beta stage? Or did you reach a stable API version? (for which we could consider that later minor revisions to come would not break backward-compatibility) If yes, since which version of Geonetwork?

These questions around the Geonetwork API are conditioning the upgrade of Geonetwork, and they are various institutions I’m interacting with that unfortunately do not make this step, because of this beta stage. Given this, they prefer to stick with the old API, even if it is not standardized and completed as the new one could be.

[eblondel]

Reply from Geonetwork team (2018-02-16): https://sourceforge.net/p/geonetwork/mailman/message/36226504/

• Is the old API yet dismissed, and if yes since which version of Geonetwork?

In 3.4.x the old API is still available, but services that has been replaced in the new API has been annotated in the code as deprecated. Unfortunately there's no documentation about the deprecated services andthe new services replacing them. That would be nice to have.

• Is it still the new API in beta stage? Or did you reach a stable API version? (for which we could consider that later minor revisions to come would not break backward-compatibility) If yes, since which version of Geonetwork?

I don't know the reason to indicate it's still in beta, I think probably that applies to GN 3.0.x, where this new API was started, but in 3.4.x all the new services are added in the new API and the UI has been updated to use the new services instead of the deprecated ones. But there're also still some services not migrated and still in the old API (these services for sure haven't been deprecated).

About not breaking backward-compatibility, this is also something we should consider to version the API in case of such changes are required. For now I don't think we got to that case (possibly as didn't pay much attention tobackward-compatibility for now), but it's something that should be managed properly.

[eblondel]

With GN 4, legacy API is dismissed, in favour of the OpenAPI.
Some refactoring is done to split GN managers, in order to keep backward compatibility for users having to use the old legacy API. Still it's to define from which version the new API would be introduced (starting with GN 4 as 1st test), with some flexibility where user could choose, for recent GN 3.x versions, between the legacy API and the new API. A 1st refactoring is done at d65fce8