As of February 14th 2024, RFC 9512opens in a new tab formally registers application/yaml as the media type for all YAML content, and adds +yaml as a standard structured suffix for all YAML-based more specific media types. With this registration, it's now included in the official media types listopens in a new tab maintained by the IANA.
Media types like this (also known as the MIME types, from their original invention for email attachment metadata) are heavily used particularly in HTTP Content-Type headers for both requests & responses, and in all sorts of file metadata and processing logic elsewhere. These names give applications a common vocabulary to describe data when passing it around.
The additional +yaml suffix also defined here is particularly useful. Media type structured suffixes like this (+xml and +json are other common examples) are used to define specific types for content that's based on an existing generic content type (such as YAML). In this case, this notably opens the door to standardization of other YAML-based MIME types, such as application/openapi+yaml (for OpenAPI specifications that are written in YAML) which is currently being formalized in another standardopens in a new tab, following closely behind this one.
While a few applications have been using application/yaml and +yaml like this already, many haven't (e.g. Rails still usesopens in a new tab application/x-yaml, and others like text/yaml and even text/x-yaml are frequently seen in the wild) and there's never been clear agreement on exactly how this should work. Hopefully with this RFC we'll be able to start picking a single media type consistently from now on, though updating older applications here will obviously take some time.
The full RFCopens in a new tab is well worth a read if you're interested in the finer details, and discusses all sorts of more detailed questions around interoperability for an evolving language like YAML, its relationship with JSON, and the (many) security considerations to be aware of when defining a formal API around YAML data.
This RFC is just one small change of course, but the hard slog of standardization like this is an important process that helps literally keep everybody on the same page. Everybody being able to agree on what YAML is actually called when sharing metadata should make it much easier to build software that more easily & reliably integrates together around YAML data in future.
Congratulations to everybody involved in the RFC and the HTTPAPI working group at the IETF who pushed this through!
Want to debug your OpenAPI APIs and even inspect YAML HTTP traffic up close? Try out HTTP Toolkitopens in a new tab now.
Suggest changes to this pageon GitHubopens in a new tab
