I’m working on a project where we want to access the GeoServer REST api to create several resources. Specifically, those are Workspaces, Data Store, Layer, Group Layer and Style.
I am trying to find out whether the data/fields that can be input for the creation of those via the web UI is generally also available via the REST api.
Seeing that GeoServer has a web UI using Apache Wicket, a server side rendering framework, and does therefore not seem to use the REST API for frontend/backend communication, there could in principle be some fields that are available via the web UI, but not via REST.
So, can you tell me whether the REST API is in general equivalent to the web UI for creation of those objects?
The REST API is occasionally more capable than the Apache Wicket Administration Console. A few administration tasks require manually editing files in the GEOSERVER_DATA_DIRECTORY for example (the security/rest.properties file controlling access to the REST API has no user interface equivalent).
We do our best to ensure that the administration console can do everything the REST API can. If you spot anything missing please let us know.
context: My understand is that many of the organizations investing in GeoServer have taken the time to automate their installations with the REST API, as a result new functionality occasionally starts with the REST API first.
Hi,
your analysis is correct and the concern warranted.
However, both the REST API and the Web UI, in the end, have to save the configuraton somewhere, that is, in the XML files found in the data directory.
The REST API XML representation is basically a 1-1 match to the models stored in the data directory, with the exception of references by id being replaced by links to other REST resources.
Long story short, in terms of data representation, they are substantially equivalent, everything you can configure with the GUI can be also configured via the REST API, once you figure out how it’s represented.
The usual advice is to do something with the GUI, see how it alters the REST XML representation, and repeat it using the REST API alone.
There are however possible deviations from this pattern:
Sometimes the UI has more functionality not found in the REST API (and I talk about functionality, not data representation, here). For example, you can do full text filtering in the layers/stores/styles tables, but you cannot do the same in the REST API
Some extensions might be storing their configuration in custom files that are not exposed via REST, or not via GUI, or neither of them.