Content Negotiation Implementing Support for XML
In this section, we will discuss another concept of RESTful Web Services that is content negotiation.
Content Negotiation
A resource can have many representations, mostly because there may be multiple clients expecting different representations.
Content negotiation is the process of selecting the best representation for a given response when there are multiple representations available. It is a part of HTTP that makes it possible to serve different versions of a document at the same URI.
In web API, content negotiation is performed at the server side to determine the media type formatted to be used based on return the response for an incoming request from the client-side. Content negotiation is centered on the media type and media type formatter.
Server-driven vs. Agent-driven Content Negotiation
An algorithm located at the server makes the selection of representation for a response, which is called server-driven negotiation.
An agent makes the selection of representation for a response, is called agent-driven content negotiation.
So, most of RSET API implementations rely on agent-driven content negotiations. Agent driven content negotiation rely on the usage of HTTP requests or resource URI patterns.
Content negotiation using HTTP headers
An incoming request may have an entity attached to it. To determine the type of entity server uses the HTTP request header Content-Type. There are some common content types are: application/json, application/xml, text/html, images/jpg, etc.
HTTP header ACCEPT is used to determine what type of representation is desired at the client-side. It contains a value as mentioned for Content-Type.
If there is no header is present in the request, the server can send preconfigured default representation type.
Content negotiation using URL patterns
There is another way to pass content type information to the server. The client can use a specific extension in resource URIs. For example, a client can request for the following:
The first request URI returns the XML response, and the second URI returns the JSON response.
Defining Preferences
The preference is defined through the q parameter that has values between 0 and 1. If the client does not specify the request header, it takes the implicit value, i.e., 1.
If the client is not sure about its desired representation and wants to give multiple values in the accept header. For example:
The above accept header allows you to ask the server for a JSON format. If the JSON format is not present, it will look for XML format. If the XML format is not possible, let it return what it can.
All services we are created until now only work with JSON input and JSON output. If we want to send a GET request by using HTTP header application/xml, it will return the status: 406 Not Acceptable.
The above image shows that XML is not a valid accept header. Let’s see how to implement XML format to one of the representations that are supported.
Step 1: Open pom.xml and add jackson-dataformat-xml dependency.
Step 2: Re-launch the application.
Step 3: Open the REST client Postman and send a GET request by specifying the HTTP header Accept: application/xml.
The following image shows the response in XML format.
Similarly, we can send a GET request for a specific user.
Let’s send a POST request using the same HTTP header.
- Under the Header tab add Content-Type: application/xml and Accept: application/xml.
- Select the Body tab.
- Enter the name and dob of the user in XML format.
- Select the XML format XML (application/xml).
- Click on the Send button.
We get the Status: 201 Created. It means that user has been created successfully. Now it can support both the formats XML and JSON.