Skip to main content

4.8. Defining Message Content

4.8. Defining Message Content​

Applications using HTTP MUST specify the format of request and response content, typically by defining one or more media types [RFC6838]. When doing so, they SHOULD register those media types following the procedures in [RFC6838].

Common formats include:

  • JSON [JSON]

  • XML [XML]

  • CBOR [RFC8949]

  • Protocol Buffers

  • Custom formats specific to the application

When specifying content, applications SHOULD:

  • Use existing, widely-understood media types where possible (e.g., application/json for JSON content).

  • Define new media types when necessary, using the appropriate tree (e.g., application/vnd.example.myapp+json for a vendor-specific format based on JSON).

  • Clearly specify the structure and semantics of the content.

  • Consider supporting multiple representations of the same resource, using content negotiation (see [HTTP] Section 12).

  • Use the Content-Type header field to indicate the media type of the content being sent.

  • Use the Accept header field to indicate the media types the client is willing to receive.

Applications SHOULD support content negotiation to allow clients and servers to agree on the representation of a resource. This is done using the Accept header field in requests and the Content-Type header field in responses.

For example, a client might send:

Accept: application/json, application/xml;q=0.9

indicating that it prefers JSON but will accept XML with a slightly lower preference.

The server can then respond with the most appropriate representation based on what it can provide and the client's preferences.

Last updated on