PATCHは、既存のリソースの一部の情報を更新するために使用され、PUTは、そのリソースの古い情報を新しいものに置き換えるために使用されます。今、AngularJSでこのコンセプトをどのように実装する必要がありますか？AngularJSでPATCHとPUTを使用するタイミング
一つの可能性の方法であってもよい： - コントローラで
、フォームを介してユーザによって変更されたフィールドの数を計算し、すなわち、50％のような閾値を設定した場合、フォームの50％以上フィールドが更新された後、
$http.putに電話をかけるか、$http.patchに電話してください。
このコンセプトを適用する標準的な方法はありますか？上記の方法は正しい方向にありますか？
実際には、APIが各リソースで使用する必要があるリクエストタイプをどのように確立するかにかかっています。理想的な世界では
、あなたがなります
POSTを使用してください。例えばPOST /v1/carsという2つの要求が発生すると、/v1/cars/1と/v1/cars/2が作成されます。PUTを使用してリソース属性を更新します。理想的には、すべての属性が同じ値を保持していても変更されている場合です。要求本体（ペイロード）には、すべての属性を含める必要があります。 PUTはidempotentです。つまり、同じリクエストボディ（ペイロード）を持つ2つのリクエストPUT /v1/cars/1を作成すると、識別子1の車に属性で更新されます。N個の同一の要求が、同じ更新/変更されたエンティティ表現で終わる。PATCHを使用して、リソースに対して部分的な変更を実行します。あなたが車1のメイクとモデルだけを更新していて価格は更新していないのであれば、APIがサポートしている限り、パッチは理想的です。実際には、あなたの質問に答えるために、使用しているAPI（バックエンド）を作成する人は、何に動詞を使うべきかを決定します。したがって、実際には、アップセルとアップデート、POSTの作成、POSTのGETを行うためのPOSTが使用されています。
angle.jsアプリが依存しているバックエンドを制御できる場合は、できるだけそれらのガイドラインにできるだけ近づけてください。しかし、それは単なるガイドラインであり、施行する必要はなく、何度もビジネス上のニーズによって、あなたはそれらから逸脱する必要があります。部分的なエンティティの更新、完全なエンティティの更新のためのPUT、またはすべての部分（部分/完全）のためのPATCHにはPATCHを使用します。あなたはあなたのために働くものを見つけるでしょう。あなたがあなたの質問に書いたパーセンテージのルールを忘れてしまって、それは事を複雑にするだけです。
私は個人的に、完全な部分的な更新としてパッチを使用します。だから私はAPIの2つのリソース更新方法をサポートする必要はないので、私はPUTをサポートしていません。しかし、私の同僚の中には、彼らのチームとパッチとしてPUTを使っている人もいます。だから彼らはパッチをサポートしていません。彼らはPUTを使って部分的な更新を行います.PUTはPUTとその顧客にも役立ちます。
しかし、フロントエンドで部分的な変更か完全なものかをどのように考えているのでしょうか？ –
パッチがサポートされている場合は、パッチを使用して終了し、ビジネスニーズを満たすために属性を更新/送信します。私の現在の会社では、Patchはサポートされていませんが、PUTはAPIの部分的な更新を許可しています。部分的な更新にはPUTを使用しています。フロントエンドでPUTを使用したり、送信する内容を心配したりする必要はありません。各ケース。また、未送信の属性をヌルなどで上書きすることについても心配する必要はありませんが、実際にはAPIによる契約がどのように定義されているかで決まります。 – Juan
PUTは、あなたは、リソースに関するいくつかの情報がキャッシュされ、他方がない場合は、パッチを使用して置くことができ、例えば、非常に特定の更新プログラムのPATCHを使用することができますPUT vs POST in REST
を見る更新し、POSTを作成するために使用されます別々にキャッシュリフレッシュを引き起こす明確な方法として別々に実行されます。
これを考えるもう一つの方法は、他のリソースとの関係を持つ複雑なリソースを更新することです。
PATCHを使用して既存のものに関係を追加することができますが、POSTはリスト全体を上書きします。
正直言って、私は通常PUTを使って作成しますが、PUTを使って既存のエンティティを上書きすることはできません.PODだけを更新してください。私は基本的にので、部分的にしかHTTP、次のい
：
完全なエンティティを送信しているときに、PUTとPOSTだけ変更のセットを送信しているとき、私は常にPATCHを適切と考えていました。過去には、たとえば、ほとんどの場合、すべてのフィールドをクライアントに送信していないというセキュリティモデルがあるため、すべての更新でPATCHを使用したプロジェクトで作業しました。それは常に技術的にデルタでした。 –
@MattHollandそれは事実上全体的なポイントです。私はそのための適切な例を見つけようとしていました。私が常にオブジェクト全体を送信するだけの挿入専用フィールドを除いて、私は自分でPATCHを使用することはできません。 – Walfrat
PUTとPOSTの違いは、PUTが冪等であることです。同じペイロードを持つ複数のPUT要求は、複数のPOST要求が複数のエントリが作成されたような複数の副作用をもたらすPOSTとは対照的に、同じ更新されたエンティティになります。私は状態やアドバイスはPOSTが更新には良いとは思いません。 PATCH/PUTは仕事のためのものです。上のすべての場合、各動詞/要求が最終的に使用されることになっている場合、実際には、これらの要求には何も行わせることができます。 – Juan
上の '' PUT'は、更新するPATCH'を作成します。この閾値/ 50％のナンセンスが何であるかわからない... – scniro