ユーザーデータを削除するか、それを空のリソースで置き換えますか？
たとえば、公開のREST APIを使用して、ユーザーがPOST、GET、DELETEを使用してデータを操作できるようにします。APIは、サービスAを介して公開され、バックエンドでサービスBを呼び出し、ほとんどのビジネスロジックをです。
最近、削除の処理方法について話し合いました。
アプローチ1：サービスBは、ユーザーが削除を要求したときにデータを削除できるように、サービスAに明示的な削除APIを提供する必要があります。
アプローチ2：もう1つの引数は、ユーザーが削除を要求したときに、サービスAがサービスBが提供するPOST APIを使用して「空のリソース」を書き込むことができるということです。これは削除と同じです。
私は2番目のオプションに不快感を表明しましたが、なぜ最初のオプションの方が優れているかをグループに納得させることができませんでした。
2つのアプローチの長所と短所は何ですか？
削除、または「空」にするために何かを上書きすることは破壊的な操作であることを考えると、私は間違いなくエンドポイントを望まない何かを更新して何かを破壊するために使用します。
このリソースを使用している誰かとして、私は削除によって何かが完全に削除されることを期待します。
また、リソースを更新して本質的に消去したり、「空」にしたりするエンドポイントは想定していません。 「空の」リソースは、ビジネスルールおよび制約の違反のように見えます。
これは予期しない動作であり、頻繁に目にするものではありません。
私はグレッグ・バーガルトに同意しますが、私は別の角度からそれに来るでしょう。
理想的には、PUT POSTオペレーションは、書き込まれたデータを検証する必要があります。PUT/ POSTに空のデータを書き込むことは、非常に可能性の高いバグです。リクエストにデータがあること、および/または定義された構造は、多くのデータ破損の問題を防ぐ方法です。
空のレコードをDELETEとして使用する場合、これを行う方法はなく、エラー（空のレコードの書き込み）と意図的な削除（空のレコードの書き込み）を区別できません。 DELETEを明示的にすることにより、これら2つのシナリオを区別します。
また、補足として、DELETEを実装したからといって、データを完全に削除する必要があるわけではありません。 1つのオプションは、レコードを削除済みとしてマークし（「ソフト」削除ともいいます）、削除済みとして扱うことです。レコードを削除として上書きすると、少なくともこのオプションはかなり厄介なものになります。
HTTPはアプリケーションプロトコルです。アプリケーションドメインは、ネットワークを介したドキュメントの転送です。 HTTP仕様には、そのプロトコルの参加者が使用する要求メッセージと応答のセマンティクスが記述されています。
したがって、REST APIはファサードです-有用な作業を実行する方法を知っているいくつかのサービスを採用し、HTTP準拠のドキュメントストアとしてそれを偽装しています。すべての有用なビットは副作用であり、実行されますドキュメントの操作を説明するメッセージへの応答。
Jim Webber： RESTfulシステムのドメイン駆動設計 を参照してください。
RESTはWorld Wide Webです。HTMLはGETとPOSTによってすべてを実行します。すべてのドメインプロトコルは、「ここから始めて、これらのリンクをたどり、このフォームを見つけ、入力してください詳細を送信してください。「このレコードをデータストアから削除/廃棄/アーカイブしてください」というフォームを送信するプロトコルを作成することは完全に合理的です。
「Appleゴミ箱に捨ててください）」というメモを誰かに書くのと同じです。ドキュメント（メモ）をお届けしますAppleゴミは副作用であり、何が起こったのか（または問題があった場合は起こらなかった）についてのメモが返されます。
さらに、 [〜＃〜] delete [〜＃〜] は奇妙な鳥のようなものです...
DELETEメソッドは、オリジンサーバーがターゲットリソースとその現在の機能の間の関連付けを削除することを要求します。実際、この方法はUNIXのrmコマンドに似ています。以前に関連付けられた情報が削除されることを期待するのではなく、OriginサーバーのURIマッピングに対する削除操作を表します。
比較的少数のリソースでDELETEメソッドを使用できます。その主な用途は、ユーザーがその効果について何らかの指示を与えるリモートオーサリング環境です。
ドキュメントストアをキーと値のペアのマップと考える場合、DELETEセマンティクスは「キーをマップから削除してガベージコレクションが値を取得する」ではなく、「キーをマップから削除する」と言います。
サーバーは実際に値を削除する場合があります。しかし、代わりにトゥームストーンを追加したり、データをnullにしたり、データをそのままにして、それをデコードするために使用した暗号化キーを破棄したり、値をそのままにしたりして、そのtarget-uriを介して到達できないことを認識できます。 ..セマンティクスに一致する動作を実装する方法はたくさんあります。
重要な洞察は、HTTP仕様では何をしなければならないかを示しているのではなく、genericの参加者（HTTP対応のキャッシュなど）が何であるかを記述しているということです。彼らが見る要求と応答について推測することを許可されています。
もう1つの引数は、ユーザーが削除を要求すると、サービスAはサービスBが提供するPOST APIを使用して「空のリソース」を書き込むことができるということです。
したがって、Roy Fieldingによってリストされている、ここで何が起こっているかについての主な引数： REST APIはハイパーテキスト駆動である必要があります
RESTは手がかりの必要性を排除しません。 RESTが行うことは、事前の知識を必要とすることを容易に標準化できる形式に集中させることです。
Webが機能するのは、多くの標準と新しい標準を作成するためのプロトコルを共通に共有し、誰もがDELETEの意味、PATCHの意味、および方法に同意できることです。プロセスへ application/problem+json、 等々。
あなたの状況では、同じチームがサービスAとサービスBの両方を管理していますか？標準化されていない帯域外情報のコストは（少なくとも短期的には）非常に低くなります。 RPCの「ドキュメントを読むだけ」のアプローチは、仕事を完了するのに十分かもしれません。
もう1つの考慮事項は、これら2つのサービス間のネットワークの信頼性です。 DELETEは、POSTで約束されていないべき等のセマンティクスを約束します。これにより、信頼性の低いトランスポートが原因でメッセージが失われた場合に、生活が楽になります。