API Element - Quality of Service

[ilkkarinne]

• Path: /qos
• Description: Service metadata about the expected quality of service (QoS)
• Type: metadata resource
• Rationale: standard endpoint and data structure for the QoS metadata would
  • allow automatic/assisted monitoring/testing the service against the declared QoS statements,
  • allow discovery for information about the operational status and operating hour limitations for the service,
  • allow discovery and subscription for upcoming events affecting service quality, and
  • mitigate unintentional strain to services by guiding the monitoring tools and bots to choose representative operations (and constraints for those operations) for automated/assisted QoS monitoring.

Resource details Structured document describing the quality of service metadata for the entire service including some or all of the following information:

• operating info:
  • operational status: operational, pre-operational, non-operational
  • operating hours (if not 24/7)
• list of quality of service statements applicable for the entire service (monthly service availability %, capacity in requests per second etc.)
• list of representative operations
  • may have request constraints
  • may have operation specific quality of service statements (like expected max response time)
• operating anomaly feed with a link to RSS/iCal feed etc. listing the upcoming events that will or may affect the quality of service (scheduled downtimes etc.)

[cmheazel]

@ilkkarinne One problem, an API may expose a collection of servers. Each server may have its own QOS (one reason to have multiple servers). It may be better to associate QOS with the Server object in the OpenAPI document.

[jyutzler]

I could see this as an option on a collection (since QOS is not necessarily uniform). However, I don't want "Common" to be a dumping point of good ideas. I want "Common" to be a gathering point for solutions that are developed under other SWGs that are candidates for use across the OGC API baseline. My recommendation is to close this issue and for interested parties to bring it up under a specific SWG. If the SWG determines that it is relevant, flesh it out and test it through some sort of sprint / testbed / etc. activity.