4

API の新しい機能を設計している最中で、ジレンマに遭遇しました。

1 対 N の関係を持つ 2 つの異なるタイプのリソースがあります。表現とレイヤー。表現には複数のレイヤーを含めることができます。Layer は 1 つの Representation にのみ属することができます。私たちが立ち往生しているのは、表現内のレイヤーの順序を維持する必要があるということです。

そして、次の 2 つのアプローチを考え出しました。

最初のアプローチ:リンクされたリスト

各レイヤーは、その前のレイヤーについて知っています。DB では、これは、別のレイヤーの ID を含むレイヤー テーブルに「親」フィールドを持つことによって実現されます。最初のレイヤーには、NULL に設定された「親」があります。

これは、次の URI によって API を介して公開されます。

作成

GET /Representations/{repID}/layers

表現のすべてのレイヤーを取得します。順序は、すべてのレイヤーを調べて、親フィールドを確認することで解決できます。

POST /Representations/{repID}/layers

本体: ラベル: (文字列) 親: LayerId

これは、要求本文で Parent を指定することにより、レイヤーを作成して特定の位置に挿入するために使用されます。Parent を NULL に設定すると、新しく作成されたレイヤーが順序の最初のレイヤーになります。親フィールドを省略した場合、新しく作成されたレイヤーは順序の一番下に配置されます。これに関する問題は、応答で、新しい挿入のために他のレイヤーの順序が変更されたことを API コンシューマーに通知する必要があることです。

アップデート

PUT /Representations/{repID}/layers/{layerId}

body: Label: (文字列) Parent: LayerId ここでも、新しい Parent を指定してレイヤーを並べ替えることができます。また、変更された他のすべてのレイヤーに関する情報を送り返す必要があります。

消去

DELETE /Representations/{repID}/layers/{layerId}

変更された他のすべてのレイヤーに関する情報を送り返す必要があります。

2 番目のアプローチ:レイヤーを独自のリソースとして注文する

アイデアは、レイヤー自体には順序の概念がないということです。それらは単なるリソースです。次に、レイヤーの順序に関する情報を保持するのを担当するlayerorderリソースを取得します。

したがって、レイヤーの CRUD 機能は引き続き使用できます: GET - POST - PUT - DELETE

ただし、順序について知りたい場合、または順序を変更したい場合は、次の uri を使用します。

/Representation/{repId}/layersorder

このリソースは 2 つの方法のみをサポートします

GET /Representations/{repID}/layersorder

この Representation 内のレイヤー ID の順序付きリストを取得します。

PUT /Representations/{repID}/layersorder

body: [] - 新しい順序のレイヤー ID の配列。レイヤーの順序を更新します。リクエストの本文として、レイヤー ID の配列を新しい順序で渡す必要があります。(例 [1,3,2,4,6,5] )

最初のアプローチに従って、レイヤーを追加または削除するたびに、別のリソースが更新されたことを API コンシューマーに通知する必要があります。変更によって影響を受けるレイヤーのリストであった最初のアプローチでは、このアプローチではレイヤーの新しい順序 (layerorder リソース) です。

意見や同様の状況の例、および問題をどのように解決したかを聞きたいです。

ありがとう。

4

1 に答える 1

1

私はあなたが説明していることの一部を経験しました。

1つまたは複数のエンティティに影響を与えるPUT/POSTを実行する場合、変更後にオブジェクト全体を返すのが好きです。戻りオブジェクトが大きくないことを願っていますが、最初のアプローチでAPIを使用している場合は、PUT / POSTを実行してレイヤーを更新してから、更新されたレイヤー情報を使用して完全な表現オブジェクトを取得することをお勧めします。

これにより、変更を確認しやすくなり、新しい構造を使用してコードですぐに作業を開始できます。PUT / POSTを実行してから、変更を確認するために追加のGETを実行する必要があります。

2番目のアプローチの場合...API呼び出しを行うために必要な作業が多いほど、イライラします。正しく読んだかどうかはわかりませんが、2番目のアプローチでPUTを実行するには、1つのデータを更新するために表現全体とレイヤーオブジェクトを構築する必要があるようです。それはイライラするでしょう。

私は最初のアプローチの構文を好みますが、2番目のアプローチの概念を使用します。言い換えると、これはPUT / POST/GETの後に表示されると予想されるドキュメントです。


{
   "type" : "Representation",
   "id" : 1,
   "layers" : [
      { "id" : 1, "name" : "the first layer", "order" : 1, "parent" : "" },
      { "id" : 2, "name" : "the second layer", "order" : 2, "parent" : 1 },
      { "id" : 3, "name" : "the third layer", "order" : 3, "parent" : 1 }   
   ]
}

すでにソートされているので、その作業を行う必要はありませんが、万が一の場合に備えて、ソートを作成するために使用される情報もあります。私はRESTAPIを使用してこれを実行しましたが、ユーザーにとってはうまく機能しているようです。

于 2013-01-31T04:24:38.273 に答える