規模や特性に応じて選定を。APIのレスポンスフォーマットまとめ

最近のAPIではJSONをリクエスト/レスポンスフォーマットとして採用することが多いですが、サイズが決して小さくないことやパースにかかる時間などを気にするケースもあります。そこで考えてみたいのがシリアラズされたフォーマットであったり、他のフォーマットです。今回はそんなフォーマット例を紹介します。

JSON

RESTful APIで最も多いファイルフォーマットではないかと思います。JavaScriptのオブジェクトフォーマットですが、多くのプログラミング言語でパースしたり、生成できるようになっています。それだけシンプルなフォーマットであると言えます。

冗長性はあまりありませんが、JavaScript特有の波かっこの多さやダブルクォートに囲みなどはあまり好まれない部分と言えます。

google/protobuf: Protocol Buffers - Google's data interchange format

Googleが開発しているフォーマットです。XMLより3〜10倍小さく、パースは20〜100倍高速であるとしています。あらかじめプロトコル定義ファイルを作成し、コンパイルすることで多くのプログラミング言語に対応したコードが生成されます。

MessagePack: It's like JSON. but fast and small.

JSONと似ているわけではありませんが、サイズについては対JSONとして強く意識しているようです。JSONから不要な部分を削り取ったことで、サイズは大幅に減っています。対応しているライブラリも多いのですが、人による可読性が低いのが難点と言えるかも知れません。

Welcome to Apache Avro!

Java、Python、C、C++、C#などで使えるデータのシリアラズフォーマットになります。プログラミング言語が限られてしまいますが、エンタープライズな企業システムであれば採用できる可能性がありそうです。スキーマはJSONで定義します。

The Official YAML Web Site

人が読みやすいという点を重視したフォーマットです。非常に多くのプログラミング言語でサポートされていますが、APIのフォーマットよりも設定ファイルのフォーマットとして採用されることが多いようです。

Extensible Markup Language - Wikipedia

いわゆるXMLのことです。Webサービスの頃に最も使われたフォーマットです。閉じタグで囲むというのが冗長的で面倒というのが悩みのタネでした。企業間でも使えるように検証する仕組みなどもあらかじめ用意されている点が利点です。

多くの場合、XMLを解釈するライブラリはそのコードが独特なものになりがちです。JSONのようにハッシュや連想配列、Dictionaryになるわけではありません。

シリアラズされたフォーマットは人が読むことはほぼ想定されていません。そのためプログラミング言語同士の中でしか使われませんがサイズが小さかったり、高速に処理ができるようになります。サービスの規模や利用想定によって採用を考えてみても良いでしょう。