8. Principles Of Content Negotiation
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation
9. Server Driven Content Negotiation
• Client requests for resource
• Client adds HTTP headers along with URL
• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Server uses headers to choose a representation
• Server returns 406 Not Acceptable status code if it
can’t find the representation.
10. Server Driven Content Negotiation
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation
11. Accept Header
The Accept request header field can be used to specify
media types which are acceptable for the response.
GET /data/miran
Accept: image/jpg
12. Accept Header
The Accept header can also have a quality factor, a
parameter indicating the relative degree of preference
between the different Media types.
GET /data/miran
Accept: image/jpg,
image/png; q=0.8,
image/*; q=0.5,
`application/json; q=0.1
13. Accept Header
List of some media types eligible for Accept header:
● Application
● Audio
● Font
● Image
● Text
● Video
14. Accept-Charset Header
The Accept-Charset header indicates to the server what
kinds of character encodings are understood by the
user-agent.
Accept-Charset: ISO-8859-1,utf-8;q=0.8,*;q=0.7
15. Accept-Encoding Header
The Accept-Encoding header defines the acceptable
content-encoding. The value is a q-factor list that
indicates the priority of the encoding values.
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
16. Accept-Language Header
The Accept-Language header is similar to Accept, but
restricts the set of natural languages that are preferred
as a response to the request.
GET /home
Accept-Language: no,
en-us;q=0.8,
en;q=0.7
17. Other Headers for Content
Negotiation
• The Accept-CH header
• The Accept-CH-Lifetime header
• The User-Agent header
• The Vary response header
18. Content-Type Negotiation
• The server introspects the Content-Type header
• Returns 415 Unsupported Media Type status code if
content type is not supported
POST /index HTTP/1.1
Accept: application/json
Content-Type: application/json
{
"foo": "bar"
}
19. RESTful Versioning Using Content Negotiation
Putting version in the URL couples the identity (the URL)
of the resource to its representation. That was never the
intent of REST. Instead, we should use Content
Negotiation to version representations.
20. RESTful Versioning Using Content Negotiation
{
“name": {
"first" : "Chris",
"last": "Morris"
}
}
{
“name": {
"full" : "Chris
Morris"
}
}
Version
1
Version
2
21. RESTful Versioning Using Content Negotiation
HTTP/1.1 200 OK
Content-Type:
application/vnd.linn.user+json;
version=1
{
“name": {
"first" : "Chris",
"last": "Morris"
}
}
GET /users/42 HTTP/1.1
Accept:
application/vnd.linn.user+json;
version=1
Request
Response
22. RESTful Versioning Using Content Negotiation
GET /users/42 HTTP/1.1
Accept:
application/vnd.linn.user+json;
version=2
Request
Response
HTTP/1.1 200 OK
Content-Type:
application/vnd.linn.user+json;
version=2
{
“name": {
"full" : "Chris Morris"
}
}
25. Disadvantage
• The server doesn't have total knowledge of
browser.
• Shared caches are less efficient.
• The information by the client is quite verbose.
26. Conclusion
If we want to build a true REST API, we should seriously
consider using Content Negotiation. In this way, we can
effectively decouple versioning from the identity of each
resource and have a clean URL pointing to only resource.