RESTful、すべてに合う？

Question

すべてのケースでRESTアーキテクチャが適していますか？

今

Person { 
    int id; 
    String name; 
    boolean verified; 
} 

、検証人で行う第三者検証の「結果」である：

は例が考えてみましょう。前REST時代に

私はこのような何か書きたい：検証者を取得し、「アクション」の結果とフラグを更新する

www.prerest.com/person/verify 

を。

このためにRESTfulな名詞ベースのAPIを作成するにはどうすればよいですか？

上記のような動詞ベースのAPIを書くことに決めたら、RESTfulなアーキテクチャではないと思います。そしてそれは「悪い考え」と呼ばれるだろうか？

Answer 1

確認のように実行時間が長くなる可能性があります。

これをモデルにする方法の1つは、verificationリソースを導入し、POSTを使用してリソースを作成し、検証結果のLocationまたは利用可能な場合に検証結果を発見できるリソースで終了することです。

POST /person/123/verification 
--> Location: /person/123/verification/456 

Answer 2

すべてのケースのためのRESTアーキテクチャに適合していますか？

ここロイTフィールディング、writing in 2008

RESTは、複数の組織にまたがる長寿命ネットワークベースのアプリケーションを対象としてです。制約が必要ない場合は、それらを使用しないでください。

しかし、それはあなたが、私はこのような何かを書きたい事前REST時代に

を求めているものではないようです....

完全に罰金。 RESTでは、あなたの識別子に使用するスペルは気にしません。サーバーは、独自の使用のために識別子に情報をエンコードする完全な裁量権を持っています。

www.prerest.com/person/verify 

RESTに関する限り、完璧です。だから私は、上記のような、動詞ベースのAPIを記述することを決定したならば、私はそれはRESTfulなアーキテクチャではありません推測

wwww.prerest.com/223d17c3-6f6a-42b6-9ddd-599df9811ad4 

です。そしてそれは「悪い考え」と呼ばれるだろうか？

あなたのURIのスペルが心配している場合、それはすでにRESTfulアーキテクチャではありません。私はそれを約束できます。この話をStefan Tilkovで見てください。

ローカルのスタイルガイドで名詞を使用する必要がある場合は....エンドポイントによって返される文書に注意してください。 「リソース」はの統合リソースです - その名前は何ですか？クライアントは検証トークンと統合していますか？クレームチェック？レポート？