Support for unknown content-type of requests at design time


#1

The spec says:

For APIs without a priori knowledge of the response types for their responses, “/” MAY be used to indicate that responses that do not matching other defined data types MUST be accepted. Processing applications MUST match the most descriptive media type first if “/” is used.

/media/{mediaid}/content:
  displayName: Content
  get:
    description: |
      Get a media file.
    responses:
      200:
        body:
          "*/*":
            description: |
                Returns the media file.

RAML should allow the same for requests too.


#2

I’m trying to figure this out as well… I have clients I cannot change that want to send text/xml instead of application/xml and it does not accept that