Discover how to make your web service speak every client's language without extra hassle!
Why Content type negotiation in Spring Boot? - Purpose & Use Cases
Imagine building a web service that must send data to different clients: some want JSON, others want XML, and some want plain text.
You try to write separate code for each format and manually check client requests to decide what to send.
Manually checking request headers and writing separate code for each format is slow and error-prone.
It's easy to forget to handle a new format or mismatch the response type, causing client errors and frustration.
Content type negotiation automatically detects what format the client prefers and sends the right response.
Spring Boot handles this smoothly, so you write one controller method and it adapts the output format for you.
if (request.getHeader("Accept").contains("application/json")) { return jsonData; } else if (request.getHeader("Accept").contains("application/xml")) { return xmlData; }
@GetMapping(produces = {"application/json", "application/xml"}) public Data getData() { return data; }You can serve many clients with different needs effortlessly, improving compatibility and user experience.
A public API that serves mobile apps, web browsers, and third-party services all requesting data in their preferred formats without extra code.
Manual response formatting is complex and fragile.
Content type negotiation automates format selection based on client preference.
Spring Boot makes it easy to support multiple response formats in one method.
Practice
Solution
Step 1: Understand content type negotiation concept
Content type negotiation allows the server to send data in different formats like JSON or XML based on what the client requests.Step 2: Identify the main purpose in Spring Boot
Spring Boot uses content type negotiation to automatically choose the response format that matches the client's preference.Final Answer:
To send data in the format the client prefers -> Option AQuick Check:
Content type negotiation = send preferred format [OK]
- Confusing content type negotiation with security features
- Thinking it speeds up database queries
- Assuming it manages user sessions
Solution
Step 1: Understand 'produces' vs 'consumes'
'produces' defines the response content type; 'consumes' defines the request content type.Step 2: Identify correct annotation for JSON response
@GetMapping with produces = "application/json" tells Spring Boot to send JSON data in response.Final Answer:
@GetMapping(value = "/data", produces = "application/json") -> Option BQuick Check:
produces = JSON means response is JSON [OK]
- Mixing 'consumes' with response content type
- Using wrong HTTP method annotation
- Setting produces to unrelated content types
@GetMapping(value = "/info", produces = {"application/json", "application/xml"})
public Data getInfo() {
return new Data("Spring", 5);
}
What will happen if the client sends an HTTP Accept header with value application/xml?Solution
Step 1: Check the produces attribute
The method supports both JSON and XML response formats as per the produces array.Step 2: Match client Accept header with produces
The client requests 'application/xml', which is supported, so Spring Boot will respond with XML.Final Answer:
The server responds with XML format -> Option DQuick Check:
Accept header matches produces = XML response [OK]
- Assuming JSON is always returned
- Thinking 406 error occurs if multiple produces are set
- Ignoring the Accept header
@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
configurer.favorParameter(true)
.parameterName("format")
.defaultContentType(MediaType.APPLICATION_JSON)
.mediaType("xml", MediaType.APPLICATION_XML)
.mediaType("json", MediaType.APPLICATION_JSON);
}
What is the likely problem if a client requests /api/data?format=txt?Solution
Step 1: Analyze configured media types
Only 'json' and 'xml' are mapped to media types; 'txt' is not recognized.Step 2: Check default content type behavior
If the parameter value is unknown, Spring Boot falls back to the default content type, which is JSON here.Final Answer:
The server will respond with JSON as default -> Option CQuick Check:
Unknown format uses default JSON [OK]
- Expecting an error for unknown format
- Assuming XML is default
- Thinking plain text is sent automatically
?type= instead of the default ?format=. Which code snippet correctly achieves this?Solution
Step 1: Enable parameter-based content negotiation
Set favorParameter(true) to allow URL parameter control.Step 2: Change parameter name to 'type'
Use parameterName("type") to listen for '?type=' instead of default '?format='.Step 3: Set default content type to JSON
defaultContentType(MediaType.APPLICATION_JSON) ensures JSON if no parameter is given.Final Answer:
configurer.favorParameter(true).parameterName("type").defaultContentType(MediaType.APPLICATION_JSON); -> Option AQuick Check:
favorParameter + parameterName = custom URL param [OK]
- Disabling favorParameter disables URL param negotiation
- Using wrong parameter name
- Setting inappropriate default content type
Ready to prove it?
Pass the test and this pattern moves unknown
