Member-only story
20 HTTP Status Codes Spring Boot Picks For You, and When It Picks Wrong
I sent 38 bad and good requests to a Spring Boot 4.1.1 app and recorded every status code. A malformed JSON body came back 401, a duplicate key 500, and a created order 200.
Here is a request with a broken JSON body, sent to an endpoint that every security rule says is open to the public:
POST /api/orders HTTP/1.1
Content-Type: application/json
{"sku": "A1", "quantity":I expected 400 Bad Request. The app sent back 401 Unauthorized, an empty body and a WWW-Authenticate: Basic header, as if the caller had forgotten a password. The endpoint sits under /api/**, which the security chain marks permitAll(). Nothing in the controller mentions authentication.
I spent an afternoon working out why, and then kept going. I built one Spring Boot 4.1.1 app (Spring Framework 7.0.9, Spring Security 7) and sent it 38 requests over real HTTP: broken bodies, missing parameters, wrong methods, failed validation, exceptions from my own code, and the happy path. For each one I recorded the status code, the headers and the exception Spring raised.
The belief this corrects is that the status codes in your API are ones you chose. Most of them were never chosen by anyone. They are Spring’s defaults for exception types you may not know exist, and…









