IDは数値じゃない文字列なんだ

IDってどんなサービスでも使いますよね。

例えば、API仕様書に以下の内容が書かれていたとしましょう。

api-spec.txt

articleId: 記事の識別子。整数値。

response-sample.json

{
  "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型で使う べきであると私は思います。
あくまでも個人的の意見なので、ぜひ みなさまのご意見をお待ちしております。