IDってどんなサービスでも使いますよね。
例えば、API仕様書に以下の内容が書かれていたとしましょう。
articleId: 記事の識別子。整数値。
{
"articles": [
{
"articleId": 1,
"text": "hoge hoge hoge..."
...
}
]
}
おそらく MySQL などの auto increment を使うとこんな感じのAPIが出来上がるかもしれません。
このようなAPI仕様書があった場合に、受け取る側では Int型などの数値型でマッピングするべきでしょうか？
私はどんな場合でもString型でマッピングするべきだと思いました。
理由
理由1: 数値型の表現できる幅はString型に比べて少ない
当たり前ですが、数値型では表現できる限界があります。
言語やOSに依存してしまいますが、32bit, 64bitの場合の unsigned integer で表現できる値は以下です。
- 32bit: 0 ～ 4,294,967,295 (42億9496万7295)
- 64bit: 0 〜 18,446,744,073,709,551,615 (1844京6744兆737億955万1615）
上記を見る限り正直なところ、サービス全体で64bitを扱えるのであれば大抵の場合は問題ないでしょう。
しかし、String型の方が数値型よりも、表現の幅は大きいので、とりあえずString型で良いと思います。
理由2: IDには様々なフォーマットがある
ID (identifier) は日本語に訳すると識別子となるように、何かを一意に識別するものです。
要素によっては、UUIDを使ったり、前述した auto increment値を使った整数値かもしれません。
しかし、どんなフォーマットであっても要素を一意に特定する意味しかありません。
IDがどんなフォーマットでもいいよう、受け取る側ではとりあえずString型としておけばいいと思います。
よくある間違いとしては 「IDが数値型の場合は登録順に並ぶから、IDでソートすればいいから数値型で持っておく方が良い」 があると思いますが、IDはあくまでもサービス内で一意な値であって、要素の大小関係を表すものではありません。絶対にIDをequal以外で評価してはいけません。
理由3: 内部での取り回しが楽
全ての場合でString型でいいじゃんとなればコードを書く場合に、楽。
正直なところ、これが一番大きい理由です。
あっちこっちで、これはIntだ！Stringだ！と考えたり変換したりするよりかは、全てStringだよと決めた方が楽ですよね。
まとめ
- 表現できる情報量が多いStringの方がベター
- IDがどんなフォーマットでも対応できるようとりあえずStringで良い
- IDはStringだ！って決めた方がコーディングが楽
以上の理由から、 特別な理由のない限りIDはString型で使う べきであると私は思います。
あくまでも個人的の意見なので、ぜひ みなさまのご意見をお待ちしております。