一般的なRESTサーバーは、jsonレスポンスをgzipなどで圧縮するべきでしょうか

Question

サーバー側でレスポンスをgzipなどで圧縮し、クライアント側でそれを展開することで通信容量を少なくし、コンテンツを取得する速度を速くすることも出来ますが、
一方で圧縮・展開に追加のリソースかかり、それが表示時間の増加に繋がってしまう恐れもあるかと思います。

一般的なプラクティスとして、jsonを返す一般的なRESTサーバー（TwitterやGithubのAPIなど）では、レスポンスは圧縮するべきなのでしょうか。

Answer 1

一般的なプラクティスとして、jsonを返す一般的なRESTサーバー（TwitterやGithubのAPIなど）では、レスポンスは圧縮するべきなのでしょうか。

一般的も何も、「リクエストがgzipを要求してきたらgzipで返す」というのが妥当かと思います。そのためにAccept-Encodingヘッダがあります（MDN）。

Comments

[maisumakun]

もちろん、すでに圧縮済みのデータは再圧縮するメリットがゼロなのでそのまま返したほうがいいです。

Answer 2

jsonを返す一般的なRESTサーバー（TwitterやGithubのAPIなど）では、レスポンスは圧縮するべきなのでしょうか。

ざっと探してみると Google API は API performance tips の「Compression using gzip」あたりの記載を読むと、クライアント側が gzip で圧縮してレスポンスしてと指示をした際に gzip 圧縮したレスポンスを返すようです。

Google 等に準じるということであれば、API レスポンスは「デフォルトは圧縮しないがユーザーからのリクエストに応じて圧縮して返すように切り替えれるようにする」という感じになるのではないでしょうか。

Answer 3

大半はウェブサーバーが勝手に処理してくれる。自分では何もしてないつもりでもすでに圧縮されている。

ウェブサーバーを挟んでないなら自分で圧縮だけど色々考慮することがあるのでウェブサーバーに任せたい。

Answer 4

今までプレーンテキストで返すAPIしか出会ったことがないです。単に圧縮モード対応に気付いてないだけかもしれませんが。

パフォーマンス要件次第で良いんじゃないでしょうか。