Content Negotiation in Spring MVC — Accept and Content-Type Headers

Direct Answer

In Spring MVC, content negotiation selects a representation for the response, usually from the request's Accept header, the mapping's produces condition, and available HttpMessageConverters. Request Content-Type is a separate concern: it describes the body the client sent and is matched by consumes. The server does not have to support every format requested by the client.

Code Example

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @GetMapping("/{id}")
    public Order getOrder(@PathVariable Long id) {
        // Client sends Accept: application/json → Jackson converts Order to JSON
        // Client sends Accept: application/xml → JAXB converts Order to XML
        return new Order(id, "Laptop", 1299.99);
    }

    @PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Order> createOrder(@RequestBody Order order) {
        // Content-Type: application/json tells Spring to use Jackson to parse body
        var saved = orderService.save(order);
        return ResponseEntity.status(HttpStatus.CREATED).body(saved);
    }
}

record Order(Long id, String item, Double price) {}

Common Mistakes & Pitfalls

• Mixing up Accept and Content-Type: Freshers often think Content-Type controls both request and response. Accept is what the client wants back; Content-Type describes what the client is sending. Sending Accept: application/xml but reading Content-Type in code leads to bugs.
• Assuming JSON is always default: If Jackson isn't on the classpath or no converter is registered, Spring won't return JSON. You'll get 406 errors. Always check spring-boot-starter-web includes Jackson.
• Ignoring 406 responses: When you see 406 Not Acceptable in Postman, it means the Accept header doesn't match any produces value. Freshers debug the controller logic instead of checking the HTTP headers first.