REST APIs can return the resource representations in a number of formats such as XML, JSON, HTML or even plain text. All such forms can be compressed to a lesser number of bytes to save bandwidth over the network. Different protocols use different techniques to enable compression and notify the clients about compression scheme – so that client can decompress it before consuming the representations.
Compression, like encryption, is something that happens to a representation in transit and must be undone before the client can use the representation.
HTTP is most widely used protocol for REST – so I am taking example of HTTP specific response compression.
Compression Related Request/Response Headers
Accept-Encoding
While requesting resource representations – along with an HTTP request the client sends an Accept-Encoding header that says what kind of compression algorithms the client understands.
The two standard values for Accept-Encoding are compress and gzip.
A sample request with accept-encoding header looks like this :
GET /employees HTTP/1.1
Host: www.domain.com
Accept: text/html
Accept-Encoding: gzip,compress
Other possible usage of accept-encoding may be:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
Content-Encoding
If the server understands one of the compression algorithms from Accept-Encoding, it can use that algorithm to compress the representation before serving it. When successfully compressed, server lets know the client of encoding scheme by another HTTP header i.e. Content-Encoding.
200 OK
Content-Type: text/html
Content-Encoding: gzip
If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type). If multiple encodings have been applied to an entity, the content encodings MUST be listed in the order in which they were applied.
Please note that original media-type for request and response are not impacted whether compression is requested or not.
Compression can save a lot of bandwidth, with very little cost in additional complexity. Also, you may know that most web browsers automatically request compressed representations from website host servers – using above headers.
Compression, like encryption, is something that happens to a representation in transit and must be undone before the client can use the representation.
HTTP is most widely used protocol for REST – so I am taking example of HTTP specific response compression.
Compression Related Request/Response Headers
Accept-Encoding
While requesting resource representations – along with an HTTP request the client sends an Accept-Encoding header that says what kind of compression algorithms the client understands.
The two standard values for Accept-Encoding are compress and gzip.
A sample request with accept-encoding header looks like this :
GET /employees HTTP/1.1
Host: www.domain.com
Accept: text/html
Accept-Encoding: gzip,compress
Other possible usage of accept-encoding may be:
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
Content-Encoding
If the server understands one of the compression algorithms from Accept-Encoding, it can use that algorithm to compress the representation before serving it. When successfully compressed, server lets know the client of encoding scheme by another HTTP header i.e. Content-Encoding.
200 OK
Content-Type: text/html
Content-Encoding: gzip
If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type). If multiple encodings have been applied to an entity, the content encodings MUST be listed in the order in which they were applied.
Please note that original media-type for request and response are not impacted whether compression is requested or not.
Compression can save a lot of bandwidth, with very little cost in additional complexity. Also, you may know that most web browsers automatically request compressed representations from website host servers – using above headers.
No comments:
Post a Comment