• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

REST API Tutorial

  • REST
  • JSON
  • Dark Mode
Home / Guides / REST Resource Representation Compression

REST Resource Representation Compression

REST APIs can return the resource representations in several 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 the compression scheme – so that the client can decompress it before consuming the representations.

Compression, like encryption, is something that happens to the resource 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 content encodings have been applied to an entity, all the encodings MUST be listed in the order in which they were used.

Please note that the original media-type for request and response are not impacted whether compression is requested or not.

Compression can save a lot of bandwidth, with minimal cost without additional complexity. Also, you may know that most web browsers automatically request compressed representations from website host servers – using the above headers.

References:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3

Was this article helpful?

Share this:

  • Twitter
  • Facebook
Previous Tutorial:
Statelessness in REST APIs
Next Tutorial:

Reader Interactions

Comments

  1. Rosen says

    July 25, 2019 at 7:53 am

    Compressing data is vital for today’s information technology, so not surprisingly it is used in client-server communication but keep in mind that loss of important parts of the transmitted files is possible, especially when it comes to sending audio/video files. You should be aware of the disadvantages of the given compression method before using it, otherwise you’re risking ending up with inconsistent data.

    Reply
    • Scott says

      April 20, 2020 at 5:41 pm

      All compression algorithms used by HTTP content encodings are lossless algorithms, so your statement is false. No loss of ‘important parts of the transmitted files’ is possible, whether those files are audio or video or not.

      Yes, there are lossy algorithms used for audio and video, but that is not relevant here. Those apply to these files _before_ they are sent via HTTP, and are not applicable to the trasmision of the file.

      Reply
    • rasnauf says

      June 1, 2020 at 2:07 pm

      In addition to Scott’s reply, check out https://en.wikipedia.org/wiki/Lossy_compression for a better understanding of the distinct use cases for lossy vs lossless algorithms. Lossy compression of images/videos/audio is usually unnoticeable to the end-user, depending on the degree of data reduction and the quality of the algorithm.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search Tutorials

Learn REST

  • What is REST?
  • REST Constraints
  • REST Resource Naming Guide

Guides

  • Caching
  • Compression
  • Content Negotiation
  • HATEOAS
  • Idempotence
  • Security Essentials
  • Versioning
  • Statelessness in REST APIs

Tech – How To

  • REST API Design Tutorial
  • Create REST APIs with JAX-RS

FAQs

  • PUT vs POST
  • N+1 Problem
  • ‘q’ Parameter

Resources

  • What is an API?
  • Comparing SOAP vs REST APIs
  • HTTP Methods
  • Richardson Maturity Model
  • HTTP Response Codes
    • 200 (OK)
    • 201 (Created)
    • 202 (Accepted)
    • 204 (No Content)
    • 301 (Moved Permanently)

Footer

References

  • The dissertation by Roy Thomas Fielding
  • Uniform Resource Identifier (URI, URL, URN) [RFC 3986]
  • Internet MediaTypes
  • Web Application Description Language (WADL)

Meta Links

  • About
  • Contact Us
  • Privacy Policy

Blogs

  • How To Do In Java

Copyright © 2020 · restfulapi.net · All Rights Reserved. | Sitemap