HTTP Status Codes for REST APIs — 200, 201, 204, 400, 404, 500

Direct Answer

HTTP status codes describe the result, not just the request method. A successful GET commonly returns 200; creation commonly returns 201 with a Location header; an update can return 200 with a body or 204 without one; DELETE can return 204, 200, or another status depending on whether it is synchronous and returns content. Use 4xx for client-facing request failures and 5xx when the server failed to fulfill a valid request.

Code Example

@RestController
@RequestMapping("/api/users")
public class UserController {
    @Autowired
    private UserService userService;

    @GetMapping("/{id}")
    public ResponseEntity<User> getUser(@PathVariable Long id) {
        return userService.findById(id)
            .map(ResponseEntity::ok)                     // 200 OK
            .orElse(ResponseEntity.notFound().build());  // 404 Not Found
    }

    @PostMapping
    public ResponseEntity<User> createUser(@Valid @RequestBody UserRequest request) {
        var user = userService.create(request);
        var location = URI.create("/api/users/" + user.id());
        return ResponseEntity.created(location).body(user); // 201 Created
    }

    @PutMapping("/{id}")
    public ResponseEntity<User> updateUser(@PathVariable Long id, @RequestBody UserRequest request) {
        var user = userService.update(id, request);
        return ResponseEntity.ok(user);  // 200 OK
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
        userService.delete(id);
        return ResponseEntity.noContent().build(); // 204 No Content
    }
}

Common Mistakes & Pitfalls

• Returning 200 for POST: Freshers often return 200 OK after creating a resource. The correct code is 201 Created with a Location header. Clients may parse the Location header to get the new resource's ID without parsing the body.
• Returning 200 for DELETE: Using 200 OK with an empty body for DELETE wastes bytes. 204 No Content clearly signals success with no content and is the HTTP standard.
• Using 500 for client errors: Returning 500 when the client sends bad data is wrong—500 means your server code crashed. Use 400 for invalid input. The client shouldn't retry a 400, but they might retry a 500.
• Not using 404: Returning an empty object or null with 200 when data doesn't exist forces clients to check if the body is empty. 404 makes the absence explicit and idiomatic.