8

タスク：1回のHTTP呼び出しで更新する必要のある複数のリソースがあります。

更新するリソースタイプ、フィールド、および値は、すべてのリソースで同じです。

例：IDで車のセットを作成し、すべての車の「ステータス」を「販売済み」に更新する必要があります。

従来のRESTFulアプローチ： [{id：1、status：sold}、{id：2、status：sold}、...] のようなJSON本文を持つ PUT/carsのようなリクエストURLを使用します

ただし、これはやり過ぎのようです。ステータスを表示するには回数が多すぎます：販売済み

ステータスを送信するためのRESTfulな方法（つまり、可能な限り「標準」のレストプロトコルに近い方法）を探しています。更新する車のIDのリストとともに、すべての車に対して1回だけ販売されます。これは私がすることです：

/cars をJSON {ids= [1,2、...]、status：sold}でPUTしますが、これが本当にRESTfulなアプローチであるかどうかはわかりません。

何か案は？

また、追加の利点として、次のようなパラメーターを使用してURLを設定するだけで、少数の車のJSONを回避できるようにしたいと思います。

PUT /cars?ids=1,2,3&status=sold

これはRESTfulで十分ですか？

4

2 に答える 2

2

さらに簡単な方法は次のとおりです。

{sold:[1,2,...]}

要求の数が多い場合も少ない場合も、複数のメソッドを用意する必要はありません。開発時間が無駄になり、パフォーマンスや帯域幅に大きな影響はありません。

RESTful である限り、受信者が簡単に解読でき、必要な情報がすべて含まれている限り、問題はありません。

于 2012-05-29T15:10:57.917 に答える
0

私が理解しているように、リソースの単一のプロパティを書き込むには put を使用するだけでは不十分です。1 つのアイデアは、プロパティをリソース自体として単純に公開することです。

したがって、ボディ コンテンツが「販売済み」の PUT /car/carId/status。

リクエストは単一のリソースのみをターゲットにする必要があるため、複数の車を更新すると複数のプットが発生するはずです。

別のアイデアは、「バッチ」リソースを構築する特定のプロトコルを公開することです。

POST /daily-deals-report/ body content {"sold" : [1, 2, 3, 4, 5]}

その後、システムは取引が行われたことを確認し、車のステータス自体を更新するだけです。このようにして、まったく新しい視点を作成し、実際に意図したよりも REST のような API を有効にします。

また、利用可能なすべての車をリストするリソースを公開することを検討する必要があります。

GET /cars/pricelist?city=* -> 車の ID と価格を含む、販売可能なすべての車のリスト。

このように、車には誰が車を所有しているかに関するステータスがありません。通常、リソースはその所有者から独立しています (所有者は、その複合体ではなく、車を集約しています)。

操作をリソースにマッピングするのが難しい場合は常に、オブジェクト指向の考え方によってモデルに欠陥が生じる傾向があります。リソースの設計は、サービスで考えるよりもさらに抽象的であるため、リソースでは多くの関係 (親プロパティ) とステータス プロパティが見当違いになる傾向があります。

多くの同様のオブジェクトを操作する必要がある場合は、それらの変更をトリガーするビジネス プロセスを特定し、その入力を記述する単一のリソースによってこのプロセスを公開する必要があります (日次取引レポートと同様)。

于 2013-11-18T13:21:39.357 に答える