Operations Metadata

[KathiSchleidt]

INSPIRE requires the provision of operations metadata:

The Operations metadata parameter provides metadata about the operations implemented by the Download Service. It shall at least provide a description of each operation, including as a minimum a description of the data exchanged and the network address.

In classic OWS services, there is an explicit section ows:OperationsMetadata listing all requests supported by the service (i.e. GetCapabilities, GetFeature)

In OGC API, the /api page provides this information

I see 2 ways forward here (but would be very thankful for good ideas!):

• dump a half-assed Open-API doc for STA somewhere and reference this. I know that there are some attempts out there. A true version doesn't work because of the flexibility of STA, there are so many options for accessing via the data model graph that the API doc would become infinite. However, in order to get past this level of bureaucratic BS, I'd be fine with a trivialized version (which I believe already exists)
• claim that our "operations" are actually HTTP GET, PUT, PATCH, DELETE, set up some simple descriptions for STA behavior on each

[hylkevds]

An Open-Api v2 of STA can be found here: https://github.com/Glagnar/OGCSensorThings/blob/master/Swagger-Source/cloud-api.json

[KathiSchleidt]

We should inform @Glagnar of our use - just not sure how to contact him...

[hylkevds]

Just for fun I did a little path counting. Including the MultiDatastream extension I came to 342 non-recursive, non-userdefined paths.

	STA 1.1	+MultiDS	Total	+MultiDS
/v1.1	1	1	1	1
/v1.1/Collection	8	9	9	10
/v1.1/Collection(entityId)	8	9	17	19
/v1.1/Collection(entityId)/Relation	16	24	33	43
/v1.1/Collection(entityId)/property	37	46	70	89
/v1.1/Collection(entityId)/property/$value	37	46	107	135
/v1.1/Collection/$ref	8	9	115	144
/v1.1/Collection(entityId)/Relation/$ref	10	15	125	159
/v1.1/Collection(entityId)/Relation/property	29	46	154	205
/v1.1/Collection(entityId)/Relation/property/$value	29	46	183	251
/v1.1/Collection(entityId)/Relation/Relation	13	19	196	270
/v1.1/Collection(entityId)/Relation/Relation/$ref	10	14	206	284
/v1.1/Collection(entityId)/Relation/Relation/property	12	20	218	304
/v1.1/Collection(entityId)/Relation/Relation/property/$value	12	20	230	324
/v1.1/Collection(entityId)/Relation/Relation/Relation	5	9	235	333
/v1.1/Collection(entityId)/Relation/Relation/Relation/$ref	5	9	240	342
/v1.1/Collection(entityId)/property/sub/property	∞	∞+	∞	∞+
/v1.1/Collection(entityId)/property/sub/property/$value	∞+	∞++	∞+	∞++
/v1.1/Collection(entityId)/Relation(entityId)/Relation(entityId)/…	∞++	∞+++	∞++	∞+++

[KathiSchleidt]

so love it when you get bored! ;) But, a very convincing argument on why Open API only really works on simple stuff... While APIs self-documenting is nice, this shows why we have underlying standards instead of redefining the wheel each time!