How can I handle a successful response that has no JSON body?
Quick answer
Check the endpoint contract before reading the response body. If it specifies a bodyless success such as HTTP 204, handle success without calling response.json(). If it specifies a JSON representation, parse JSON for that result. Don’t assume every successful status has the same body shape: some successful responses include data and others do not. [S1]
The question, the details, the next step.
My fetch() call succeeds, but await response.json() throws an error because there’s nothing to parse. How should I handle that?
Choose how to read the response from the endpoint’s documented response shape, not just from the fact that the request succeeded. A 204 No Content response has no response-body content, so there is no JSON value to parse. A successful response such as a documented 200 may include a JSON operation result. [S1]
For a documented bodyless result, handle success without reading JSON. For a result documented to contain JSON, parse the body. Calling response.json() unconditionally assumes every success contains JSON, which may not match the contract. The exact statuses and body shapes depend on the API; the guidance describes the distinction, not a rule for every endpoint. [S1]
Can you show both cases in one example? Assume I have an update endpoint that might return either JSON or no content.
Assume the endpoint contract says an update returns either 204 with no body or 200 with a JSON object. Use the documented status to choose the reader:
if the response status is 204:
handle success without reading a body
else if the response status is 200:
parse the JSON objectThis example makes the expected shapes explicit: 204 means no body, while 200 means a JSON object. If your endpoint documents additional success statuses or different body shapes, add a branch for each one rather than assuming every other success contains JSON. A 204 has no response-body content; a 200 may include an operation result. [S1]
What if I don’t know whether the endpoint returns JSON? Can I just try parsing and ignore the error?
First check the API documentation or ask the team that owns the endpoint what success statuses and response bodies it specifies. Don’t make a failed JSON parse your normal way of deciding what success means: it can hide a mismatch between your assumption and the endpoint’s contract. If you control the API, make the expected success shape explicit and handle each documented outcome.
If the contract allows different representations, use its rules to decide which result to expect. An absent or unexpected body may mean the response differs from your assumption; decide how to handle that deliberately rather than silently treating every parse failure as “no content.”
How should I structure this if one endpoint returns a JSON result and another returns no body?
Keep response handling specific to each endpoint’s documented result. Use JSON parsing only for an endpoint whose contract supplies JSON; handle a documented bodyless result without trying to parse a JSON value. That is clearer than forcing both endpoints through the same reader and hoping their response bodies match.
Microsoft’s Fetch tutorial illustrates this distinction in its ASP.NET Core to-do examples: its GET and POST examples parse JSON, while its PUT and DELETE examples continue without parsing a body. Those examples are for that tutorial’s API, not a guarantee about other APIs. Follow the contract for the endpoint you call. [S2]
A practical checklist
Look up the endpoint’s documented success statuses and response-body shapes.
For a documented 204 response, handle success without reading JSON.
Parse JSON only for outcomes documented to contain JSON.
Decide how to handle unexpected statuses or a body that doesn’t match the contract.
A few more useful answers
Does every successful response have a JSON body?
No. A 204 No Content response has no response-body content, while other successful responses may include a representation. Check the endpoint contract rather than assuming one shape for every success. [S1]
Should I parse JSON just to find out whether the body is empty?
Use the documented response shape to choose whether to parse. If the contract specifies a bodyless result, handle success without trying to read a JSON value; if it specifies JSON, parse that result.
Can I use the same handling for another API’s PUT or DELETE endpoint?
Only if that API documents the same response shape. The Microsoft tutorial’s PUT and DELETE examples skip body parsing, but that is an illustration for its specific API, not a universal rule. [S2]
Sources
References used for this guide.
- [S1] Web API design best practices: response status codes and representations learn.microsoft.com · Checked
- [S2] Call an ASP.NET Core web API with JavaScript: Fetch response handling learn.microsoft.com · Checked