Sending REST response in plain text or JSON?
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.
IMB
Updated on June 27, 2022Comments
-
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 almost 12 yearsThe choices are still up to me right? (e.g., I only want JSON or plain text, no XML) or XML is also required?
-
michelson almost 12 yearsNothing is really required. The client can ask for
Accept: application/foo
and you can respond withContent-Type: text/json
. TheAccept
header is a preference from the view of the client and theContent-Type
header is an assertion that the enclosed entity body meets the requirements of a specific MIME type. -
michelson almost 12 yearsAccording to RFC4627, JSON-Text is defined as either an array or an object.