Angular.js: $ resourceにモデルを更新するためのPUTがないのはなぜですか？

他の人は、それがどのように機能し、名前が付けられるべきかについて異なる意見を持っています。 これはどう？

更新-> PATCH（部分更新）
置換-> PUT（リソースを置換）
作成-> POST（新しいリソースを作成）

もう少し下にスクロールすると、独自のメソッドを作成する方法について次の例が見つかります。

var notes = $resource('/notes/:id', null, {
  'update': { method:'PUT' }
});

@ jimmywarting-あなたの答えは回避策であり、解決策ではありません。

var notes = $resource('/notes/:id', null, {
  'update': { method:'PUT' }
});

notes.prototype.$save = function() {
    if (this.id) {
        return this.$update();
    } else {
        return this.$create();
    }
};

@jansorenあなたの提案は、一般的な方法でコーディングするのが難しい多くの質問を提起します、IMO。 元。：

作成および更新アクションを使用して$ resourceを拡張することは可能ですか？

• 保存と作成の違いは何ですか？
• 更新に使用されているHTTP動詞について、バックエンドが異なれば意見も異なるようです。 PUT、POST、PATCHが使用されているのを見ました。

idがnullの場合はcreateを呼び出し、idが設定されている場合はupdateを呼び出すために、保存アクションをオーバーライドすることもできますか？

• idどのように識別しますか？

さまざまなバックエンドによってさまざまにアプローチされるものの一般的な解決策を求めているように思われるので、ここで最善の行動方針が何であるかはわかりません。

RESTを実装する際の課題は、RESTと同じように変化する場合に見られます。 そうは言っても、AngularJSチームがそれをどのように解決したいかについてのガイダンスを提供することを願っています。 現時点では、例はあいまいに見えます。

@ pkozlowskiへの応答-オープンソース：

• saveとcreateの違い。 saveは、リソースを作成するときにPOSTし、リソースを変更するときにPUTします。 createは、POSTとリソースの作成のみを使用します。
• リソース全体を更新する場合はPUTを使用し、リソース全体の一部を更新する場合はPATCHを使用します。 パッチは、ドメイン駆動設計でうまく機能すると思います。

@shlenskyの助けを借りて、私はこの例を作成しました：

resource.js

(function () {
    var resource = function ($resource) {
        var resource = {};
        resource.create = function(url) {
            return createResource($resource, url)
        }
        return resource;
    };

    var createResource = function($resource, url) {
        var resource = $resource(url, getParamDefaults(), getActions());
        resource.prototype.$save = function() {
            if (this.id) {
                return this.$update();
            } else {
                return this.$create();
            }
        };
        return resource;
    };

    var getParamDefaults = function() {
        var paramDefaults = {
            id:'<strong i="17">@id</strong>'
        };
        return paramDefaults;
    };

    var getActions = function() {
        var actions = {
            'create': {method:'POST'},
            'update': {method:'PUT'},
            'all':    {method:'GET', isArray:true}
        };
        return actions;
    };

    angular.module('myModule').factory('resource', resource);
}());

CreditCard.js

(function () {

    var CreditCard = function (resource) {
        return resource.create('card/:id');
    };

    angular.module('myModule').factory('CreditCard', CreditCard);
}());

myController.js

(function () {
    var myController = function ($scope, CreditCard) {
        // get
        var creditCard = CreditCard.get({id:'abc123'}, function() {
            console.log(creditCard);
        });

        // all
        var creditCards = CreditCard.all(function() {
            console.log(creditCards);

            // update
            var creditCard = creditCards[0];
            creditCard.name = 'changed';
            creditCard.$save(function() {
                console.log(creditCard)
            });
        });

        // create
        var creditCard = new CreditCard();
        creditCard.name = 'new';
        creditCard.$save(function() {
            console.log(creditCard)
        });
    };
    angular.module("myModule").controller("myController", myController);
}());

クライアントは、作成中か更新中かをどのように知るのでしょうか。 それは本当に知りません。 実際、クライアントの開発者は、作成する必要があるのか​​更新する必要があるのか​​を自分で知る必要があります。

@caitpこれは私が尋ねようとしていた正確な質問です:-)

作成/更新の違いを知るには、問題をさらに複雑にするある種のID表記を導入する必要があります。 また、IDが入力されていない場合、オブジェクトは保存されないと想定します。

@jansorenチームからの現在のガイダンスは明確だと思います。$ resourceには、ほとんどのRESTfulバックエンドに適したデフォルトが付属しています。 シーンがそれほど明確でない場合は、カスタム/追加メソッドの形式で拡張ポイントがあります。 $ resourceは非常に拡張可能であり、率直に言って、$ httpに基づいてラッパーのような$ resourceを構築するのは非常に簡単なので、$ roesoureの一部として考えられるすべてのユースケースをキャプチャすることは意味がありません。

デフォルトでは、IMO $ resourceには、多数のバックエンド/シナリオに共通するものだけが含まれ、十分なフレックスポイントを残して、より「エキゾチックな」バックエンド/シナリオ（またはコンセンサスがない状況）に拡張できるようにする必要があります。

method 、

@ caitp-上記の私の例でカバーされています：

 resource.prototype.$save = function() {
            if (this.id) {
                return this.$update();
            } else {
                return this.$create();
            }
        };

@ pkozlowski-オープンソース-私はそれがまだ改善する可能性があると言っているだけです。 そして、ngResourceのドキュメントが次のように述べているウィキペディアを参照しているのは奇妙だと思います。 リソースを更新するためのPUTと、リソースを作成するためのPOST。 PUTがngResourceに標準として実装されていないのはなぜですか？ （私の最初の質問に戻る）
開発者は、より単純な場合でも、構成方法を受け入れる傾向があります。

PUTとPOSTの違いは、作成するのか更新するのかではなく、リソースを編集するのか、リソースの子を編集するのかということです。 RFC 2616から：

PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。

...対...

POSTメソッドは、リクエストに含まれるエンティティを、Request-URIで識別されるリソースの新しい従属としてオリジンサーバーが受け入れるようにリクエストするために使用されます。

ほとんどのRESTfulシステムでは、これは最終的に作成および更新されますが、これは保証ではありません。そのため、私はAngularの現在の中性用語であるPOSTのsave大ファンです。いずれにせよ意味合い。 また、POSTを呼び出すcreate関数を追加しても、他の人が指摘しているように、サーバーとの通信がsaveと区別できないため、役に立たないことに同意します。

_しかし_、私はPUTメソッドを含めるのが大好きです。PUTは定義上べき等であるため（上​​記のセクション9.1.2を参照）、リクエストの複数のコピーは通常、単一のコピーと同じ結果になります。 POSTにはこのプロパティがなく、サーバーはリクエストの複数のコピーを個別に解釈し、それぞれに重複するリソースを作成することがよくあります。 私の考えでは、「標準」のRESTツールボックスには重複しない編集ルートが少なくとも1つあるはずなので、これは含める価値があるのに十分です。

私が使用する2つのバックエンドRESTリソースの実装には、PUTが含まれます。

• Laravelのリソースコントローラーには、 Route::resourceメソッドのデフォルト部分としてPUT /resource/{resource} -> updateがあります。
• ExpressJSのリソースパッケージには、まったく同じPUT /resource/{resource} -> update非常によく似たマッピングがあります。

さらに、そこにある何百ものルーティングライブラリは、ほぼすべてがPUTを不可欠なコアメソッドであると考えています。

確かに、それがないことは_壊れた_ことではありませんが、すべてのデフォルトを使用してから、定義するすべての$resourceに独自のPUTを追加する必要があるのは奇妙に感じます。

@tdhsmith
私はあなたに同意します。PUTメソッドがあると非常に興味深いでしょう。私は彼を「update」と呼び、PATCHは「partial_update」になります。

これらの名前はDJangoREST Frameworkから取得しました。ジェネリックビューには、次の2つの方法があります。

def update（self、request、pk = None）：
パス

def partial_update（self、request、pk = None）：
パス

バックエンドRESTの正しい実装には、更新を実行するメソッドPUTが必要だと思いますが、誰もがそれを実装しているわけではないことを私は知っています。
ASP.NETでの現在の実装には、PUTメソッドがありません。これは、c＃が厳密に型指定されているため、バックエンドで制御フローを実装する方が簡単だからです。

ただし、データアプリのv1でPUTメソッドを要求するのはかなり一般的なようです。 +1は、これらの数行のコードをAngularに標準で含めることを可能にする規則を見つけるためのものです。

カスタムメソッドを$ resourceに追加する非常にクリーンな方法の1つについては、 http：//kirkbushell.me/angular-js-using-ng-resource-in-a-more-restful-manner/を参照してください。

@sjatkins私にとって、それはより多くの回避策です。

また、$ resourceにはPUTのデフォルトオプションが必要であることに同意します。レコードを更新するために、PUTを使用する必要があるたびに手動で構成する必要があるのは奇妙に思えます。これは非常に一般的なIMOです。 PATCHのデフォルトのオプションについては、少し一般的ではありませんが、議論することができますが、PUTの少なくとも1つは妥当です。

また、人々は$ saveと$ createの違いは何でしょうかと尋ねていました。 ええと、多分$ deleteと$ removeの同じ違い、つまり何もありませんか？ エイリアスに問題はありません。ngResourceにもすでに問題があります。

リソースはRestに基づいていると想定されているので、httpのRestfulルートが焼き付けられていないのはなぜですか...

例：

{
    'get':    {method:'GET'},
    'post':   {method:'POST'},
    'update': {method:'PUT'},
    'query':  {method:'GET', isArray:true},
    'delete': {method:'DELETE'}
};

バックエンドが異なれば、使用すべき動詞についての意見も異なります。
$resourceは一般的なソリューションを提供し、簡単に拡張できます。

基本的に、 $resourceProvider.defaults.actionsを使用してデフォルトのアクションを設定できます。
これを文書化せずに残すことが意図的なものなのか、それとも単なる見落としなのかはわかりません。

それはとても空想的です。それでは、リソースをもう一度提供します。 拡張可能なコンポーネントが大好きです！

ドキュメントが更新され、デフォルトのアクションに関するより明確な情報が追加されました。 これにより、必要に応じてPUTを簡単に構成できるようになります。