Sending REST response in plain text or JSON?

14,113

Solution 1

Use the client-provided Accept header to let the client control what content type they want. If no header is provided, then use a sensible default and always include a Content-Type header in the response. See the Content Negotiation section of RFC2616 for more details.

Solution 2

Theoretically, returning just "1" is valid JSON. It's just not a array or associative mapping.

For OK and Accepted, you can just use the HTTP status codes for those. No body is really necessary.

Share:
14,113
IMB
Author by

IMB

Updated on June 27, 2022

Comments

  • IMB
    IMB almost 2 years

    When creating a REST API, if I return data in JSON format for GET requests, is it a good practice to also send responses for POST, PUT, DELETE, and error messages in JSON too or plain text will suffice?

    For example:

    For POST request where I need to return the new ID of the newly added record (i.e. just the new auto increment value in database), should the response still be in JSON or just plain text like "1" or "2" for example.

    Same goes for PUT or DELETE request where I need to say "OK" or "Accepted", as well error messages like "Bad Request", "Not Found", etc.

    Plain text or JSON?

  • IMB
    IMB almost 12 years
    The choices are still up to me right? (e.g., I only want JSON or plain text, no XML) or XML is also required?
  • michelson
    michelson almost 12 years
    Nothing is really required. The client can ask for Accept: application/foo and you can respond with Content-Type: text/json. The Accept header is a preference from the view of the client and the Content-Type header is an assertion that the enclosed entity body meets the requirements of a specific MIME type.
  • michelson
    michelson almost 12 years
    According to RFC4627, JSON-Text is defined as either an array or an object.