IVOA Recommendation: IVOA Support Interfaces

This document describes the minimum interface that a (SOAP- or REST-based) web service requires to participate in the IVOA. Note that this is not required of standard VO services developed prior to this specification, although uptake is strongly encouraged on any subsequent revision. All new standard VO services, however, must feature a VOSI-compliant interface. This document has been produced by the Grid and Web Services Working Group. It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. IVOA’s role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability inside the Astronomical Community.

💡 Research Summary

The IVOA Recommendation “IVOA Support Interfaces” (VOSI) defines a minimal, standardized set of web‑service endpoints that any SOAP‑ or REST‑based service must expose in order to participate fully in the International Virtual Observatory Alliance (IVOA) ecosystem. The specification is aimed at improving discoverability, health‑monitoring, and automated interoperability of astronomical data services across the globe.

VOSI is built around three core resources: capabilities, availability, and tables. The capabilities endpoint returns an XML (or JSON) document that enumerates every IVOA standard the service implements (e.g., TAP, SIA, SSA), together with version numbers, service URLs, and optional authentication requirements. This enables client software to dynamically discover which protocols are supported without hard‑coding service‑specific details.

The availability endpoint provides a real‑time health check. Its response contains Boolean flags indicating whether the service is currently operational, timestamps for the last start‑up, any scheduled downtime, and an optional free‑text note. HTTP status codes (200 for healthy, 503 for unavailable) are required, and error conditions must be reported using the standard VOError format. This resource is essential for automated workflow engines that need to route jobs around failing services or trigger alerts for administrators.

The tables endpoint describes the data model exposed by the service. For services that implement the Table Access Protocol (TAP), this includes a list of tables, column names, data types, units, UCD (Unified Content Descriptor) tags, and primary‑key information. Clients can query this metadata to construct ADQL statements on the fly, enabling truly dynamic data discovery and analysis pipelines.

Implementation guidance is provided for both SOAP and REST styles. SOAP services must declare the VOSI URLs in their WSDL and support HTTP GET for metadata retrieval. REST services follow a simple URL convention (e.g., /vosi/capabilities, /vosi/availability, /vosi/tables) and must serve the correct MIME types (application/xml or application/json). The specification explicitly states that VOSI does not impose its own authentication scheme; however, if the underlying service requires authentication, the same mechanism must be applied to VOSI calls to prevent unauthorized metadata exposure. Cross‑origin resource sharing (CORS) headers are recommended for web‑based clients.

A critical part of VOSI’s value proposition is its tight integration with the IVOA Registry. Registry harvesters periodically crawl the three endpoints of every registered service, ingesting up‑to‑date capability lists, health status, and table schemas. This harvested information populates the global service catalog that astronomers use to locate data resources. Services that fail to implement VOSI risk being omitted from the registry or appearing with stale metadata, reducing their visibility and scientific impact.

The document also addresses migration for legacy services. While existing services are not forced to adopt VOSI retroactively, the recommendation strongly encourages updates, especially for any new version of a standard service. A migration guide outlines how to map older metadata formats to the VOSI schema, ensuring backward compatibility.

Future work outlined in the recommendation includes an optional JSON‑LD representation for richer semantic descriptions, alignment with the OpenAPI specification to simplify client generation, and extensions for performance metrics (latency, throughput) that could be consumed by automated load‑balancing systems.

In summary, VOSI establishes a lightweight yet comprehensive contract that every IVOA‑compliant service should fulfill. By standardizing how capabilities, availability, and data schemas are advertised, VOSI enables automated discovery, robust monitoring, and seamless integration of heterogeneous astronomical services, thereby strengthening the overall functionality and interoperability of the Virtual Observatory community.