私が働いているプロジェクトの仕様から、ユーザーエンティティのステータスを[VALID | NOT_VALID |検証します ]。 /ユーザー/：：私は更新したいのでuser_idを/ステータスRESTリソースの単一の属性を更新するためのApiデザイン
私の考えは、URLとPOSTのための新しいサブパスを追加することでした のuser_id：ユーザーのための
現在のAPIは /ユーザーが/このパスを持っています一番良いと思われる選択肢を設計する単なる価値ですか？例えば、クエリ文字列を使用して要求の本体（JSON）
感謝。
ステータスがクエリー可能でない場合は、/ user /：user_idのようなユーザーエンティティ自体の一部としてステータスを持つこともできますし、ステータスを更新するためにPATCH（JSONペイロード付き）を実行することもできます。一般に、サブパスが単独でサブリソースとして照会されるか、独立して更新される場合、ネストされたパスが優先されます。誰かがユーザーのステータスを必要とするなら、/ user /：user_idのGET結果にそれが来るとは期待しないでしょうか？または、彼は/ user /：user_id/statusに別のGET呼び出しを行う必要がありますか？私は、/状態のパスは素晴らしい考えではないかもしれないと思います。
また、ステータスのようなものを追加すると、今後名前、住所などを更新する必要がある場合にどうなりますか。すべてのフィールドに新しいサブパスを追加し続けるつもりはありませんか？また、URLパスにenumのようなサブパス（valid/not_validなど）を持つことは、正しいことではないようです。それをJSONペイロードに含めると、スキーマの下に来るので、enumに新たに追加する場合に備えて、バージョンをうまくバージョンアップすることができます。それをURLの一部として持つことは、クライアントが新しいパスについても知っている必要があることを意味します。
一方、APIのユーザビリティについて考える必要があります。 REST APIの設計には一般的に従います.2分ほどでクライアントとAPIを統合し、正常に統合するために必要なものを最小限に抑える必要があります。すべての標準と規範は、ユーザビリティの第二になるかもしれません。
こちらを参照してください。http://stackoverflow.com/questions/2443324/best-practice-for-partial-updates-in-a-restful-service –