Last updated
Last updated
This new proposed capability is currently undergoing Member and Public review.
We'd love to hear your feedback on this draft! Use the #content-capability-development channel on OCTO Slack, or comment on on the draft here:
To use this capability add octo/content to your Octo-Capabilities header.
This capability extends the Supplier, Product, Option, Unit, Availability and Booking schemas to add additional descriptive content that can be used to populate product listings as well as for various for other use cases that require this information.
Since suppliers and their systems may offer content in different languages, this content capability supports localization through Accept-Language request header as well as Content-Language and Available-Languages response headers as described below.
Content capability enriches existing OCTO Core Supplier, Product, Option, Unit, Availability, and Booking objects with additional information listed below when octo/content is added to the Octo-Capabilities the header of the request of any OCTO Core containing this object, given that the supplier system supports this capability.
See the list of proposed fields in the Google Sheet below. The updated OpenAPI file with the proposed content fields will be published in the coming weeks.
...rest of headers...
-
See Headers section.
Accept-Language
Optional
This optional request header allows to specify preferred languages for content in the response.
A language code that specifies the language of the product content. This code must conform to the BCP 47 standard, following RFC 5646 and RFC 4647 specifications for language tags. Examples include en-US for American English, fr-FR for French (France), and es-ES for Spanish (Spain).
This header also supports a comma-separated list of language tags with optional quality values (q) to indicate priority, such as en-US, fr-CA;q=0.8, fr;q=0.7, which prioritizes American English, followed by Canadian French, and general French. Note this only determines preference and does not guarantee location has content available in the desired language. The * (wildcard) can also be included, such as in en-US, fr;q=0.9, *;q=0.5, to indicate a preference for any language if the specified ones are not available.
This header approach is defined in the HTTP/1.1 specification (RFC 7231) and is commonly used for internationalized websites and services to enhance user experience. For more details, visit MDN Web Docs: Accept-Language - HTTP
...rest of headers...
-
See Headers section.
Content-Language
Required with octo/content
This header indicates the language of the content fields provided in the response.
Only one language is returned per response, following BCP 47 standards (e.g., en-US, fr-FR).
To retrieve content in multiple languages, separate requests must be made.
This header is also defined in the HTTP/1.1 specification (RFC 7231) and follows existing standard.MDN Web Docs: Content-Language - HTTP Example:
Available-Languages
This header lists all the languages in which content is available, helping clients understand available language options without additional requests.
Also following BCP 47 standards (e.g., en-US, fr-CA, es-ES),
This header is commonly used in APIs, but is non-standard HTTP header.
Adds extra content fields to OCTO Core object schemas on select endpoints to provide detailed descriptive information about supplier, products, options, units, booking, etc.