同じエンティティに対して 2 つの識別子があり、それぞれを個別に使用するとエンティティにマップできるユース ケースがあります。1 つの識別子はクライアント フレンドリ (c_id など) で、もう 1 つはサーバー フレンドリ (s_id など) です。クライアントは s_id を知っていますが、ほとんどの場合、それを使用しません。サーバーは両方の ID を認識していますが、サーバーでの実装では、すべてが s_id を使用して簡単にマップされるようになっています。このような場合、c_id と s_id の両方のレベルでリソースを提供することをお勧めします。この場合、リソース名と id (入力) が異なり、同じことを行いますか、それとも単一のリソースのみである必要がありますか?どのリソースを使用すべきかという議論につながります。
質問する
70 次
3 に答える
0
API は、ユーザーの利益のために存在します。できるだけ簡単にするよう常に努力する必要があります。すべてのリソースに一意のクライアント フレンドリ ID が存在する場合は、API がクライアント フレンドリ ID に対して機能するようにします。API は clientId から serverId へのマップをメモリに保存し、より快適な ID に簡単に切り替えることができます。
すべてのリソースに一意のクライアント フレンドリ ID がない場合は、問題があります。ギャップを埋めることから始めます (つまり、残りのリソースに clientId を与えます)。それが不可能なら、私はダミアンに同意します。
于 2013-08-05T19:20:19.287 に答える
0
通常、リソースはサーバー ID の下に存在し、適切なリソースに 302 リダイレクト (または必要に応じて 307) を返す検索メソッドを提供します。クライアントは、これらの検索/クエリ メソッドを使用して、正しいリソースに到達します。
サーバーはリソース (およびその URL) を「所有」しているため、URL をいじってリソースに到達しても問題ありません。一方、クライアントはリソースを見つけるために URL をいじる必要がないため、クエリ文字列パラメーターとして知っている ID を指定できるクエリ メソッドをクライアントに提供すると、よりクリーンに感じられます。
于 2013-08-05T07:43:42.100 に答える