バックグラウンド
クライアントが地理空間オブジェクトを操作できるようにする API を構築しています。これらのオブジェクトには、世界の場所 (緯度/経度) と、適切なメタデータが含まれています。実際の API はかなり大きいので、簡略化したバージョンをここに示します。
現在の API
機能と属性の 2 つのオブジェクトを持つ API を考えてみましょう。
機能のエンドポイントは/api/feature次のようになります。
{
id: 5,
name: "My super cool feature",
geometry: {
type: "Point",
coordinates: [
-88.043355345726,
43.293055846667315
]
}
}
属性エンドポイントは/api/attribute. 属性は次のようになります。
{
id: 3,
feature_id: 5,
name: "attr-name",
value: "value"
}
ご想像のとおり、さまざまな HTTP メソッドを使用してエンドポイントに HTTP 要求を発行することで、これらのオブジェクトと対話できます。
GET /api/feature/5ID 5 の機能を読み取ります。PUT /api/feature/5ID 5 でフィーチャーを更新します。POST /api/feature新しい機能を作成します。DELETE /api/feature/5ID 5 のフィーチャーを削除します。
属性についても同様です。
属性は、外部キーによって機能に関連付けられます (一般に、「機能には多くの属性がある」と表現されます)。
問題
フィーチャとそのすべてのメタデータ (それに属するすべての属性) のコピーを作成できると便利です。ユースケースは多かれ少なかれ、「私はこの機能を作成し、それにたくさんの属性を与えました。今は同じものが欲しいです...しかし、そこにあります。」したがって、2 つの機能の唯一の違いは、それらの形状です。
解決策 1: クライアントに実行させる。
私が最初に考えたのは、クライアントにそれをやってもらうことでした。新しい場所に同じ名前の新しいフィーチャを作成し、ソース フィーチャのすべての属性を反復POST処理して、新しいフィーチャにそれらのコピーを作成するリクエストを発行します。ただし、これにはいくつかの問題があります。まず、アトミックではありません。このプロセス中にクライアントのインターネット接続が不安定になると、不完全なコピーが残ることになります。第二に、特に多くの属性を持つ機能の場合、おそらく遅くなります。とにかく、これは悪い考えです。
解決策 #2: API にコピー機能を追加します。
1 回の API 呼び出しでサーバー側でコピーを行う方が、より適切な方法です。これにより、https://www.rfc-editor.org/rfc/rfc2518#section-8.8とそのCOPY方法にたどり着きます。COPY /api/feature/51 回のリクエストで機能のディープ コピーを実行できることが理想的です。
質問
私の問題は、ここでのセマンティクスが、COPY私が想定している用途に完全に適合しないことです。リソースに対してリクエストを発行するCOPYと、そのリソースのコピーがDestinationヘッダーで指定された宛先に実行されます。RFC によると、Destination存在する必要があり、コピーされたリソースの最終的な場所を指定する URI である必要があります。私の場合、コピーされた機能の宛先はジオメトリであり、これは明らかに URI ではありません。
Destinationだから、私の質問は次のとおりです。ジオメトリのjsonをリクエストのヘッダーに詰め込むCOPYことは、仕様の倒錯ですか? COPYここで使用するのも正しいですか？そうでない場合、どのような代替手段がありますか? これを最もHTTPコーシャな方法で実装していることを確認したいだけです。