抄訳 RFC7493 I-JSON

社用のAPIのガイドラインを整備したいと思っていたところ、I-JSONというものがあることを教わったので見てみました。

概要

• I-JSON = Internet JSON

  • Web上で複数のシステム間が互いにJSONデータを扱いやすいようにするための、その記述(およびパーサの実装)についてのガイドライン

• RFC7493 で規定されている

  • IETFが2015年に作成し、IESGが承認している
  • RFC7159 におけるJSONの定義をベースとしている

参照

• IETF - RFC7493: I-JSON
• IETF - RFC7159: JSON

I-JSONのルールまとめ

エンコード

• (MUST) エンコードは UTF-8 を使うこと
• (MUST NOT) オブジェクトのkey/valueおよび配列内の文字列にサロゲートペア(4バイト文字)やUnicode外の文字を含めてはいけない

数値

• (SHOULD NOT) IEEE754 で定義された倍精度小数点より大きな(桁数の)数を数値としてJSONに含めるべきではない
• (SHOULD NOT) 2^53 より大きい/小さい整数を数値としてJSONに含めるべきではない
  • (RECOMMEND) これらを扱いたい場合は文字列で表現するのが望ましい

日付と時刻

• (RECOMMEND) 日付と時刻は RFC3339 / ISO8601 で定められた文字列形式で表現することが望ましい
• (RECOMMEND) 期間を指定する場合も同様に RFC3339 に準ずることが望ましい

加えて以下を満たすことが推奨される:

• アルファベットは大文字を使うこと
• タイムゾーンがデフォルトであっても明示されること
• 秒が00であっても明示されること

バイナリ

• (RECOMMEND)バイナリを含める場合は base64url によってエンコードすることが望ましい

オブジェクト

• (MUST NOT) オブジェクト内に重複するキーがあってはならない
• (MAY) I-JSONにおいて、オブジェクト内のキーの順序のみが異なるメッセージは等価とみなせる
  • つまりオブジェクト内のキーの順序は保証されない

バリデーション

• JSONメッセージがI-JSONのフォーマットに準拠していない場合、受信者は受信を拒否することができる

• (SHOULD NOT) オブジェクトと配列以外をトップレベルに使うべきでない

  • 古いJSONの仕様(RFC4627)による実装との互換性を確保するため

• (MUST NOT) 受信者が認識できない要素が出現しても、その事実をエラーとして扱ってはいけない

  • これはフォーマットではなくデータ構造の話(例えば知らないキーがオブジェクトに含まれてるとか)
  • Must-Ignoreポリシ = 理解できない要素は無視する