The spec, in the Body section, states:
A method’s body is defined in the body property as a hashmap, in which
the key MUST be a valid media type.
The Responses section state:
Each response MAY contain a body property, which conforms to the same structure as request body properties (see Body).
Note that neither section makes any reference to a default media type.
So from reason this, we’d assume that the keys of
body property hashmap MUST be valid media types.
Alas, Mulesoft’s sample RAML APIs, such as Twitter’s, show things like:
responses: 200: body: schema: ... example: ...
Presumably this is because the
mediaType root property has been, so that is the expected request and response body media type.
The Default Media Type section says
The media types returned by API responses, and expected from API requests that accept a body, MAY be defaulted by specifying the mediaType property.
But nowhere does the spec discuss the fact that the
body property instead of being keyed by media types, can contain the properties associated with the default mediate type. In fact, only a single example in the spec uses this technique, in the Parameters section, and its not discussed.
Aside form the lack of description in the spec, this option means that you must look at the keys of the
body property and determine whether they are mediate types and if and only if they are not, assume the user mean to use the default media type and that the keys are the body properties.