POSTの前にプレビューを表示するRESTエンドポイント

RESTバックエンドとHTML + JSフロントエンドを搭載した新しいWebアプリケーションを設計しています。

1つのエンティティを変更するためのPOSTメソッドが1つあり（Configを呼び出しましょう）、アプリケーションの多くの要素の状態にいくつかの副作用があります。POSTが次のように実行されると仮定します。

POST /api/config BODY {config: ....}

このため、これらの変更が行われる前にプレビューを表示して、エンドユーザーが何が変更されるかを確認できるようにします。

私が最初に考えたのは、プレビューのGETエンドポイントを作成して、エンティティの新しい状態の本体を送信することです。こちらです：

GET /api/preview/items BODY {config: ....}

新しい構成のアイテムの新しい状態が表示される場合があります。

GET /api/preview/sales BODY {config: ....}

新しい構成での販売の新しい状態が表示される場合があります。

アプリケーションの状態を変更しないので、GET動詞を使用することをお勧めします。ただし、GET要求での要求本体の使用は推奨されないようです。

これについて良い習慣はありますか？他の選択肢として、1つの方法で構成をドラフトとして保存し、他の方法で結果を表示することもできますが、追加の手順が必要で、サーバーでドラフトを管理する必要があります。

POST /api/preview/config BODY {config: ....}

GET /api/preview/items?idPreviewConfig=1

これはドメイン固有であるため、HTTPでネイティブサポートできません。

代わりに、次のいずれかを実行できます。

1. がありPOST /api/config/previewます。サーバー側では、アプリケーションは実際の構成を変更してはならないことを認識しますが、実際の構成と投稿した構成を組み合わせ、変更内容を示す結果を返します。

   その後、ユーザーが結果に満足したらPOST /api/config、前のリクエストと同じペイロードを含むを実行します。これにより、構成が効果的に上書きされます。

   このアプローチの利点は、現在のAPIに重大な変更を加えないことです。プレビュー機能を必要としないクライアントは、以前と同じようにエントリを更新できます。

   欠点は、本体が大きい場合、サーバーに2回送信する必要があることを意味します。この場合、次のアプローチを使用できます。

2. 持っているPOST /api/config/prepare（例えば、一時的なレコードのID：一時的なレコードで送信されたものを記憶し、二つのことを返す12345）と変更のプレビューを。

   ユーザーが結果に満足している場合、ユーザーはPOST /api/config/commit/12345変更を確実に保存するためにを実行します。そうでない場合、一時レコードはしばらく保持され、cronジョブによって破棄される場合があります。

   利点は、ここでも、元のPOST /api/configファイルをそのまま保持でき、プレビューを必要としないクライアントが壊れないことです。

   欠点は、（1）一時レコードの削除を処理するのが難しい場合があることです（1時間で十分だと思いますか？10分後にメモリが足りない場合はどうなりますか？有効期限が切れたレコード？）、および（2）レコードの2段階送信は、必要以上に複雑になる場合があります。

3. クライアント側でプレビューロジックを移動します。

RESTのさまざまなAPI呼び出しに特定のHTTP動詞を使用するポイントは、既存のHTTPメカニズムと期待を活用することです。

この場合にGETを使用すると、両方に反するようです。

A.クライアントは、GETで本文を含める必要がありますか？予想外

B.サーバーは、本文に応じてgetに対して異なる応答を返しますか？仕様とキャッシングの仕組みを破る

RESTfulな質問に苦労している場合、私のルールは自問することです。

「これは、すべてにPOSTを使用するよりも優れていますか？」

すぐに明らかなメリットがない限り、Just Use POST Stupid（JUPS）戦略を使用します

サーバーに「これを永続化せず、実行した場合の結果のみを表示する」ことを示すヘッダーを送信できます。例えば

POST /api/config HTTP/1.1
Host: api.mysite.com
Content-Type: application/json
Persistence-Options: simulate

{
   "config": {
      "key": "value"
   }
}

サーバーが応答できるもの：

HTTP/1.1 200 OK
Persistence-Options: simulated
Content-Type: application/json

-- preview --

DBで作業単位ベースのO / RMおよび/またはリクエストごとのトランザクションを使用する場合、特定のエンドポイントでの作業を必要とせずに、すべてのエンドポイントにこの機能を簡単に実装できることに注意してください。 、コミットする代わりにトランザクション/作業単位をロールバックします。

これを検索と同じように扱うことをお勧めします。/api/config/preview新しいプレビューを作成するPOSTエンドポイントを設定します。次にapi/config、現在の構成を編集するか、単に構成全体を置き換えるかによって、PUTまたはPATCHエンドポイントをセットアップします（前者の場合は、作成したばかりのプレビューを送信します）。

他の良い答えと一緒に、別のオプションは上記のような設定を投稿し、ロールバックプロセスも利用可能にすることができます。アジャイル手法と同様に、よりきめ細かく、再現性があり、テスト済みの手順を用意することで、変更を怖がらないほうが良いと思います。これにより、必要に応じてバックアップが提供され、アプリケーションに応じてリスクがほとんどまたはまったくなくなります。

繰り返しますが、システム全体に影響する構成エラーがある場合は、より積極的に処理する必要があります。その場合は、サーバーまたはクライアントの観点から、その時点での変更のプレビューに努力を払わないでください。このプレビュー機能の開発コストがどのように高くなるかはわかりますが、ユースケースでは、独自の一連の異なる手順に従ってテストを行う必要があります。

RFC6648は新しいX-コンストラクトを非推奨にしているため、新しいヘッダーフィールドを送信するというアイデアに反対する必要があります。RESTはアーキテクチャスタイルであり、私たちが話しているのはRESTfulですが、現時点ではそれを無視します。

RESTは代表（およびシミュレーションには現実の表現がない）およびステートフル（およびシミュレーションはコミットされるまで状態ではない）であるため、シミュレーションスコープのような新しいスコープが必要です。ただし、シミュレーションにはシミュレーションのプロセスが含まれますが、ステートフルとは、シミュレーションの理想的な解決策である定常状態、つまりエミュレーションを意味するため、シミュレーションではなくエミュレーションと呼ぶ必要があります。そのため、URLでエミュレーションと呼ぶ必要があります。これも良い解決策かもしれません：

GET  /api/emulation - 200 OK {first:1, last:123}
POST /api/emulation/124 - 200 OK
GET  /api/emulation/124/config - 200 OK {config:{tax:8}}
PUT  /api/emulation/124/config {config:{tax:16}} - 200 OK {config:{tax:16}}
GET  /api/emulation/124/items - 200 OK [first:1, last: 3000]
GET  /api/emulation/124/items/1 - 200 OK {price:1.79, name:'Cup'}
--- show emulation ---
--- commit emulation ---
PUT /api/config {config:{tax:16}}
DELETE /api/emulation/124 - 200 OK

別のアプローチは、あなたがたくさんHTML / JavaScriptをクライアントが生成することからの要求の持つ気づいたかもしれません....がありますあまりにも多くのリクエストを（見たのと同じ時間に17程度の要求の限界に達したものを、このページを）。RESTの使用法を交換し、不完全なオブジェクト状態を配信する代わりに、リッチなユーザー固有のページ状態を配信できます。例：

GET /user/123/config - 200 OK {user:'Tim', date:3298347239847, currentItem:123, 
                  roles:['Admin','Customer'], config:{tax:16}, unsavedChanges:true, ...}

敬具