リソースの内部識別子 ( など) としてのシステムの場合person_id
、別の一意の値 ( など) で呼び出し可能な直接 API アクセスを提供することは理にかなっていますlicensee_id
か?
では、そのような API 設計を持つことは合理的でしょうか?
GET /people/{:licensee_id}
と:
PUT /people/{:licensee_id}
{
"name": "John"
}
つまり、あなたが話しているリソースには一意の識別子はありませんが、2 つあるということです。
私がそれを行うとしたら、次のように、2 つの異なる URL から同じリソースを公開します。
/licensee/:licensee_id
/people/:person_id
コードの一部でAPIのユーザーが人を扱っている場合(つまりperson_id
、他の呼び出しなしで簡単にアクセスできる場合)、2番目を呼び出し、そうでない場合は最初を呼び出すことができます。
その理由の 1 つは、API の消費者にとってより簡単であるという事実に加えて、実装がより簡単になるという事実に加えて、渡されるものが alicensee_id
か aかを理解する必要がないことです。person_id
このようにするのは理にかなっています。誰かが SQL インジェクション攻撃を行うのを実際に難しくする重要な情報を実際にあきらめているわけではありません (id を参照する他のテーブルのすべての外部キーはとにかく異なる名前を持つため)。
id フィールドに直接アクセスできない場合は、一意のユーザー フィールドから作成された uuid や md5 などでインデックス付けされた別の列が必要になります。このようにすることの唯一の利点は、誰かが API を使用してユーザーや他のオブジェクトを「歩く」ことができないことです。