6

次のようなメモを作成するための REST サービスを構築したいとします。

GET    /notes/     // gives me all notes
GET    /notes/{id} // gives the note identified by {id}
DELETE /notes/{id} // delete note

PUT    /notes/{id} // creates a new note if there is no note identified by {id}
                   // otherwise the existing note is updated

私は自分のサービスを不等にしたいので、PUT を使用してメモを作成および更新しています。これは、新しいメモの ID がクライアントによって設定/生成されることを意味します。

GUID/UUID を使用することを考えましたが、かなり長く、URL を覚えるのがかなり難しくなります。データベースの観点からも、このような長い文字列 ID は、大きなテーブルで主キーとして使用されると、パフォーマンスの観点から問題になる可能性があります。

短いIDを生成し、もちろん衝突を回避する優れたID生成戦略を知っていますか?

4

1 に答える 1

9

高度に分散されたシステム ( 、など) が長い UUID/ハッシュを使用する一方で、集中化されたリレーショナル データベース (または ) が単にints を使用できるのには理由があります。クライアント側で分散方式で短い ID を作成する簡単な方法はありません。サーバーがそれらを処理するか、無駄な ID を使用する必要があります。通常、これらには、エンコードされたタイムスタンプ、クライアント/コンピューター ID、ハッシュ化されたコンテンツなどが含まれます。

これが、REST サービスが通常使用する理由です。

POST /notes

非冪等保存の場合はLocation:、応答でヘッダーの出力を使用します。

Location: /notes/42
于 2012-04-04T18:48:25.000 に答える