1つのリクエストで複数のアイテムを作成するRESTfulな方法

注文を収集する小さなクライアントサーバープログラムに取り組んでいます。これを「REST（ful）」にしたい。

私がしたいのは：

すべての注文ライン（製品と数量）を収集し、完全な注文をサーバーに送信します

現在、これを行うには2つのオプションがあります。

1. 各注文明細をサーバーに送信します：POST qtyおよびproduct_id

サーバーへのリクエストの数を制限したいので、実際にはこれをしたくありません。オプション2です。

2. すべてのオーダーラインを収集して、一度にサーバーに送信します。

オプション2を実装するにはどうすればよいですか？私が持っているいくつかのアイデアは次のとおりです。JSONオブジェクトですべてのオーダーラインをラップし、これをサーバーに送信するか、配列を使用してオーダーラインをポストします。

オプション2を実装するのは良いアイデアですか、それとも良い方法ですか？

良い習慣とは何ですか？

これに取り組む別の正しい方法は、リソースのコレクションを表す別のリソースを作成することだと思います。たとえば、エンドポイントが/api/sheep/{id}あり、POSTを実行/api/sheepしてシープリソースを作成できるとします。

さて、一括作成をサポートしたい場合は、新しいflockリソースを検討する必要があります/api/flock（または/api/<your-resource>-collection、より適切な名前がない場合）。ことを覚えておいてくださいリソースは、データベースやアプリケーションのモデルにマッピングする必要はありません。これはよくある誤解です。

リソースは、データとは関係のない、より高いレベルの表現です。リソースを操作すると、ユーザーへのアラートの起動、他の関連データの更新、長期間有効なプロセスの開始など、重大な副作用が発生する可能性があります。たとえば、ファイルシステムやunix psコマンドをREST APIとしてマッピングすることもできます。

リソースを操作することは、副作用として他のいくつかのエンティティを作成することを意味することもあると想定するのは安全だと思います。

多くのシステムでは一括操作（バッチ作成など）は必須ですが、RESTfulアーキテクチャスタイルでは正式に対処されていません。

あなたが提案したようにコレクションをPOSTすることは基本的には機能することがわかりましたが、そのような要求に応じて失敗を報告する必要がある場合に問題が発生します。このような問題は、さまざまな原因で複数の障害が発生した場合、またはサーバーがトランザクションをサポートしていない場合に悪化します。たとえば、サービスプロバイダーが（WANではなく）LAN上にある場合やデータが比較的小さい場合など、パフォーマンスに問題がない場合は、100のPOST要求をサーバーに送信することをお勧めします。シンプルに保ち、個別のリクエストから始め、パフォーマンスの問題がある場合は最適化を試みます。

Facebookはこれを行う方法を説明しています：https : //developers.facebook.com/docs/graph-api/making-multiple-requests

単純なバッチリクエスト

バッチAPIは、JSON配列として表される論理HTTPリクエストの配列を受け取ります。各リクエストには、メソッド（HTTPメソッドGET / PUT / POST / DELETEなどに対応）、relative_url（graph.facebookの後のURLの部分）があります。 com）、オプションのヘッダー配列（HTTPヘッダーに対応）およびオプションの本文（POSTおよびPUTリクエスト用）。Batch APIは、JSON配列として表される論理HTTP応答の配列を返します。各応答には、ステータスコード、オプションのヘッダー配列、およびオプションの本文（JSONエンコードされた文字列）があります。

あなたの考えは私には当てはまるようです。実装はあなたの好みの問題です。あなたはこれのためにJSONまたは単にパラメータ（ "order_lines []"配列）を使用して行うことができます

POST /orders

1つのアクション（注文とその行）で一度により多くのリソースを作成するので、すべてのリソースを検証し、それらすべてが検証に合格した場合にのみ保存することが重要です。トランザクションで行う必要があります。

単一の接続内で個別のリクエストを送信する方が良いと思います。もちろん、あなたのウェブサーバーはそれをサポートするべきです

私は最近これに実際に取り組んでいますが、これが私が目指していることです。

複数のリソースを追加するPOSTが成功した場合、200 OKを返します（201を検討していましたが、ユーザーは最終的に、作成されたリソースにたどり着きませんでした）。 -のみまたは編集可能な方法。たとえば、ユーザーは、単一のファイル入力のみを含むフォームを使用して、複数の画像を選択し、ギャラリーにPOSTすることができます。POSTリクエストが完全に成功した場合、作成された画像リソース表現ごとにフォームのセットが表示され、それぞれについて詳細（名前、説明など）を指定できます。

1つ以上のリソースの作成に失敗した場合、POSTハンドラーはすべての処理を中止し、個々のエラーメッセージを配列に追加します。次に、419競合が返され、ユーザーは、送信されたフォームに戻る方法と同様に、エラー配列の内容を示す419競合エラーページにルーティングされます。

100のオーダーラインのHTTPヘッダーを送信する必要はありません。また、必要以上のリクエストを生成する必要もありません。

注文全体を1つのJSONオブジェクトでサーバーに送信します：server / orderまたはserver / order / new。次のものを指すものを返します：server / order / order_id

POSTの代わりにCREATE PUTの使用も検討してください