銀行の口座番号は知られたくないけどそれが連番で発行されていたらどうなるだろう。
名前を知りたい人の一つ後ろで口座作成をして、自分の口座番号-1の番号をATMに打ち込めば、口座名義が分かってしまう。
これは、識別子が識別以外の役目を担っている。これをやると、上記のような問題が発生する。識別子に受付順という情報空間上の位置情報をのせるのが悪い。
ではパスの扱いはどうすればいいのだろうか？
例えば、自分の住所が address.com/tokyo/akihabara/1/1 で引けるとして、区割りが変わって address.com/kanagawa/akihabara/1/1 になったらURIが変わっているだろとなる。
その場合はパス情報から辿れる住所はそれで良いのだが、同じ区画の情報が辿れるように、
address.com/location/id:100 をGETしたら、 住所の変更履歴が出てくるようにすれば良い。
一番大本の識別子に区割りという識別以外の役目を持ち、識別子に区割りという情報空間上の位置情報を含んでいるので悪い例になっている。
コードとはなにか？
受付番号の札とかそういう、今呼ばれている番号がわかれば、後どれぐらいで自分の番がくるかわかるもの。情報空間上の位置情報が含まれている文字列である。
Kanagawa だったら tokyo にすれば東京のものが取れるんだろうなとか。
識別子があるのにコードを利用しなきゃいけない場合があるのは、それが便利だからだ。
QRコードに載せなきゃいけないから短いほうがいいとか、その場で使うためには色々工夫が必要なのである。 識別子は長すぎて順番通りじゃないので、実物がある場合に隣のものを調べるのに面倒である。
これには情報空間上の位置情報を乗せるべきだ。たとえば、一日ごとに閉店する銀行なら、受付番号は毎日使いまわしても良いし、a b c じゃなくて 1234 が良い。ただし、顧客のクレーム処理のためには、今日の１番の番号札の人の顧客対応の識別子は別に振らなくてはいけない。何月何日の１番の札の人のクレームと考えて処理して、次の人にお金を盗まれました怪しいのは受付番号２番の人だということにはならない。その人はあとから来て10番ぐらいに来たかもしれないから、受付番号１番はその日に受付をした人の中で人を識別することと受付順しか保証しないのである。
郵便番号もコードであって識別子ではない。郵便局の配置によって、統合されたり別の郵便番号になったりするけど、同じ区域を指している場合もありえる。したがって、100年ぐらいの期間でそれを一意な識別子としては使えない。
識別子の設計標準は
https://datatracker.ietf.org/doc/html/rfc7320
https://datatracker.ietf.org/doc/html/rfc8820
https://datatracker.ietf.org/doc/html/rfc3986
https://www.w3.org/TR/webarch/#indirect-identification
です。設計する場合は参照してください。
No comments:
Post a Comment