Swagger.io API documentation

[glagnar]

Do you have the API documented, e.g. by swagger ?
This means I can generate clients for the OGC SensorThings API and use your component very easily. I have been working on this, but my version is by no means complete.

[mjacoby]

As the SensorThingsServer is an implementation of the Sensor Things API which is documented here we do not have any additional documentation of the API.
I'm not that familiar with Swagger in detail but I think it probably won't be able to cover the whole API specification as the query constructs can get quite complex. So I guess Swagger could only cover the basic parts of the API like access to an entity by id or an entity set. If I'm wrong here please correct me.

As the SensorThings API is based on OData, perhaps an other approach could be to use existing software that exposes OData endpoints as Swagger. There is at least some discussion on this on the OpenAPI GitHub page (see).

If you are just looking for a client to access any Server implementing the SensorThings API you can have a look at this project. It is a java client wrapping the SensorThings API.

Further, if you have any Swagger description of the API and would like to add this to the project feel free to contribute.

[mmontesinos]

Glagnar, do you have any update on this? Have you completed the swagger documentation of OGC SensorThings API?

[liangsteve]

Instead of Swagger, we have a Slate documentation. e.g., http://www.sensorup.com/docs/?javascript#filter It allows you to send requests and test SensorThings API.

[riedel]

There is a actually a simplified version here, that could be easily used as a starting point: https://docs.linksmart.eu/display/HDS/Simplified+SensorThings+API

[hylkevds]

That version at linksmart is unfortunately incorrect (Things/{id} instead of Things({id})) and also does not cover the recursive nature of STA.

[riedel]

As I think an official schema should be provided with the standard I opened an issue for standardization: opengeospatial/sensorthings#72

I still think this is an issue to easy adoption...

[hylkevds]

Also discussed on the official STA GitHub repo: opengeospatial/sensorthings#92 with links to some generated OpenAPI documents.

[volcan01010]

How does this thread relate to the OpenAPI extension?

https://fraunhoferiosb.github.io/FROST-Server/extensions/OpenAPI.html

I switched it on and got a OpenAPI document that I was able to render in the Swagger UI.

However, the generated URLs were incorrect as they missed out the FROST-Server part of the path e.g. the /api document from

http://server:8080/FROST-Server/v1.1/api

generates invalid links that point to

http://server:8080/v1.1/Datastreams

[hylkevds]

Yes, the OpenAPI extension is an experiment into generating this document.

Thanks for testing it, it seems you found a bug, though the paths are actually correct:

A relative path to an individual endpoint. The field name MUST begin with a slash. The path is appended (no relative URL resolution) to the expanded URL from the Server Object's url field in order to construct the full URL.

The bug is that there is no servers array in the generated document.

[KoalaGeo]

@hylkevds we almost have the extension working, by there's an issue with the url paths

Our end point is https://sensors-internal.bgs.ac.uk/FROST-Server/

But the extension is sending requests to https://sensors-internal.bgs.ac.uk/v1.1/Actuators for example. Is there a setting / ENV we've missed?

[hylkevds]

Yes, that's the same bug as mentioned above. I've not had time to fix it yet, but I've opened a separate issue for it: #427

[KoalaGeo]

Ah great. For now we'll change our deployment to not use /FROST-Server/