私は顧客管理システム用のRESTfulサービスを作成しており、レコードを部分的に更新するためのベストプラクティスを見つけようとしています。たとえば、呼び出し元がGETリクエストでレコード全体を読み取れるようにしたいとします。ただし、更新の場合、ステータスをENABLEDからDISABLEDに変更するなど、レコードに対する特定の操作のみが許可されます。（これよりも複雑なシナリオがあります）

セキュリティ上の理由から、更新されたフィールドのみを含むレコード全体を発信者に送信してほしくありません（また、やり過ぎのように感じます）。

URIを構築するための推奨される方法はありますか？RESTブックを読むとき、RPCスタイルの呼び出しは不快に思われます。

次の呼び出しがID 123の顧客の完全な顧客レコードを返す場合

GET /customer/123
<customer>
    {lots of attributes}
    <status>ENABLED</status>
    {even more attributes}
</customer>

ステータスを更新するにはどうすればよいですか？

POST /customer/123/status
<status>DISABLED</status>

POST /customer/123/changeStatus
DISABLED

...

更新：質問を補足します。「ビジネスロジックコール」をREST APIに組み込むにはどうすればよいですか？これを行うための合意された方法はありますか？すべてのメソッドが本質的にCRUDであるとは限りません。いくつかは'のような、より複雑なsendEmailToCustomer（123） '、 ' mergeCustomers（123、456） '、 ' countCustomers（） '

POST /customer/123?cmd=sendEmail

POST /cmd/sendEmail?customerId=123

GET /customer/count 

基本的に2つのオプションがあります。

1. 使用PATCH（ただし、正確に何が起こるかを指定する独自のメディアタイプを定義する必要があることに注意してください）

2. POSTサブリソースに使用し、303を参照してください。メインリソースを指すLocationヘッダーを持つその他を参照してください。303の目的は、クライアントに次のことを伝えることです。POST / 303は、いくつかのメインリソースの状態を構築するためにリソースに繰り返し追加することを目的としており、部分的な更新に最適です。

部分的な更新にはPOSTを使用する必要があります。

顧客123のフィールドを更新するには、/ customer / 123へのPOSTを実行します。

ステータスのみを更新する場合は、/ customer / 123 / statusにPUTすることもできます。

一般に、GETリクエストには副作用がありません。PUTはリソース全体を書き込み/置換するためのものです。

これは、次のようにHTTPから直接続きます。http：//en.wikipedia.org/wiki/HTTP_PUT#Request_methods

部分的な更新にはPATCHを使用する必要があります-json-patchドキュメントを使用します（http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-08またはhttp://www.mnot.net/を参照） blog / 2012/09/05 / patch）またはXMLパッチフレームワーク（http://tools.ietf.org/html/rfc5261を参照）。ただし、私の意見では、json-patchは、お客様の種類のビジネスデータに最適です。

JSON / XMLパッチドキュメントを使用したPATCHには、部分的な更新のための非常に厳密な転送セマンティクスがあります。元のドキュメントの変更されたコピーでPOSTの使用を開始すると、部分的な更新のために、欠損値（またはnull値）が「このプロパティを無視する」または「このプロパティを空の値」-そして、ハッキングされたソリューションのうさぎの穴につながり、最終的には独自の種類のパッチ形式になります。

詳細については、http：//soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.htmlをご覧ください。

同様の問題が発生しています。単一のフィールドのみを更新したい場合、サブリソースのPUTは機能するようです。ただし、多くのことを更新したい場合があります。一部のエントリを変更するオプションを持つリソースを表すWebフォームを考えてみてください。ユーザーがフォームを送信しても、複数のPUTが発生することはありません。

ここに私が考えることができる2つの解決策があります：

1. リソース全体でPUTを実行します。サーバー側で、リソース全体を含むPUTが変更されていないすべての値を無視するというセマンティクスを定義します。

2. 部分的なリソースでPUTを実行します。サーバー側で、これのセマンティクスをマージと定義します。

2は単なる1の帯域幅最適化です。リソースが必須フィールドであることをリソースが定義している場合、1が唯一のオプションです（protoバッファーと考えてください）。

これらの両方のアプローチの問題は、フィールドをクリアする方法です。フィールドのクリアを引き起こす特別なnull値を定義する必要があります（特にprotoバッファーにはnull値が定義されていないため、protoバッファーに対して）。

コメント？

ステータスを変更するためのRESTfulなアプローチは、リソースのステータスを説明する論理サブリソースを使用することだと思います。このIMOは、ステータスのセットが少ない場合に非常に便利でクリーンです。顧客リソースに既存の操作を強制することなく、APIをより表現力のあるものにします。

例：

POST /customer/active  <-- Providing entity in the body a new customer
{
  ...  // attributes here except status
}

POSTサービスは、次のIDを持つ新しく作成された顧客を返す必要があります。

{
    id:123,
    ...  // the other fields here
}

作成されたリソースのGETは、リソースの場所を使用します。

GET /customer/123/active

GET / customer / 123 / inactiveは404を返す必要があります

PUT操作の場合、Jsonエンティティを提供せずにステータスを更新するだけです

PUT /customer/123/inactive  <-- Deactivating an existing customer

エンティティを提供すると、顧客のコンテンツとステータスを同時に更新できます。

PUT /customer/123/inactive
{
    ...  // entity fields here except id and status
}

顧客リソースの概念的なサブリソースを作成しています。これは、ロイフィールディングのリソースの定義とも一致します。「...リソースは一連のエンティティへの概念的なマッピングであり、特定の時点でのマッピングに対応するエンティティではありません...」この場合、概念的なマッピングは、status = ACTIVEのアクティブな顧客から顧客へのマッピングです。

読み取り操作：

GET /customer/123/active 
GET /customer/123/inactive

これらの呼び出しの1つを呼び出した直後に、もう一方の呼び出しがステータス404を返す必要がある場合、正常な出力には暗黙のステータスが含まれない場合があります。もちろん、GET / customer / 123？status = ACTIVE | INACTIVEを使用して、顧客リソースを直接クエリすることもできます。

セマンティクスが混乱する可能性があるため、DELETE操作は興味深いものです。ただし、この概念的なリソースに対してその操作を公開しないか、ビジネスロジックに従ってそれを使用するオプションがあります。

DELETE /customer/123/active

これにより、顧客をDELETED / DISABLEDステータスまたは反対のステータス（ACTIVE / INACTIVE）にすることができます。

拡張質問に追加するもの。多くの場合、複雑なビジネスアクションを完全に設計できると思います。しかし、思考の方法/手順のスタイルを放棄し、リソースや動詞でもっと考える必要があります。

メール送信

POST /customers/123/mails

payload:
{from: x@x.com, subject: "foo", to: y@y.com}

このリソース+ POSTの実装は、メールを送信します。必要に応じて、/ customer / 123 / outboxなどを提供し、/ customer / mails / {mailId}へのリソースリンクを提供できます。

顧客数

これを検索リソースのように扱うことができます（ページングとnum-found情報を含む検索メタデータを含み、顧客数を提供します）。

GET /customers

response payload:
{numFound: 1234, paging: {self:..., next:..., previous:...} customer: { ...} ....}

PUTを使用して、不完全/部分的なリソースを更新します。

jObjectをパラメーターとして受け入れ、その値を解析してリソースを更新できます。

以下は、参考として使用できる関数です。

public IHttpActionResult Put(int id, JObject partialObject)
{
    Dictionary<string, string> dictionaryObject = new Dictionary<string, string>();

    foreach (JProperty property in json.Properties())
    {
        dictionaryObject.Add(property.Name.ToString(), property.Value.ToString());
    }

    int id = Convert.ToInt32(dictionaryObject["id"]);
    DateTime startTime = Convert.ToDateTime(orderInsert["AppointmentDateTime"]);            
    Boolean isGroup = Convert.ToBoolean(dictionaryObject["IsGroup"]);

    //Call function to update resource
    update(id, startTime, isGroup);

    return Ok(appointmentModelList);
}

アップデートについて。

CRUDの概念は、API設計に関して混乱を引き起こしたと思います。CRUDは、データに対して実行する基本的な操作の一般的な低レベルの概念であり、HTTP動詞は、CRUD操作にマップする場合としない場合がある（21年前に作成された）単なる要求メソッドです。実際、HTTP 1.0 / 1.1仕様でCRUDの頭字語の存在を見つけてください。

実用的な規則を適用する非常によく説明されたガイドは、GoogleクラウドプラットフォームAPIドキュメントにあります。リソースベースのAPIの作成の背後にある概念について説明します。操作よりも大量のリソースを強調するものであり、説明しているユースケースが含まれます。彼らの製品にとっては単なるコンベンションデザインですが、それは非常に理にかなっていると思います。

ここでの基本概念（および多くの混乱を招くもの）は、「メソッド」とHTTP動詞の間のマッピングです。1つは、APIがどのタイプのリソース（たとえば、顧客のリストを取得するか、電子メールを送信するか）に対して行う「操作」（メソッド）を定義することであり、もう1つはHTTP動詞です。使用する予定のメソッドと動詞、およびそれらの間のマッピングの両方の定義が必要です。

操作は、標準的な方法で正確にマッピングされない場合にも（すなわち言うList、Get、Create、Update、Deleteこの場合）、一つのような、「カスタムメソッド」を使用することができるBatchGetいくつかのオブジェクトID入力に基づいて複数のオブジェクトを取得している、またはSendEmail。

RFC 7396：JSONマージパッチ（質問が投稿されてから4年後に公開）は、形式と処理ルールの観点からPATCHのベストプラクティスを説明しています。

簡単に言うと、application / merge-patch + json MIMEメディアタイプと、変更/追加/削除するパーツのみを表すボディを含むHTTP PATCHをターゲットリソースに送信し、以下の処理ルールに従います。

ルール：

• 提供されたマージパッチにターゲット内に表示されないメンバーが含まれている場合、それらのメンバーが追加されます。

• ターゲットにメンバーが含まれている場合、値は置き換えられます。

• マージパッチのnull値には、ターゲットの既存の値の削除を示す特別な意味が与えられます。

上記のルールを説明するテストケースの例（そのRFCの付録にあるとおり）：

 ORIGINAL         PATCH           RESULT
--------------------------------------------
{"a":"b"}       {"a":"c"}       {"a":"c"}

{"a":"b"}       {"b":"c"}       {"a":"b",
                                 "b":"c"}
{"a":"b"}       {"a":null}      {}

{"a":"b",       {"a":null}      {"b":"c"}
"b":"c"}

{"a":["b"]}     {"a":"c"}       {"a":"c"}

{"a":"c"}       {"a":["b"]}     {"a":["b"]}

{"a": {         {"a": {         {"a": {
  "b": "c"}       "b": "d",       "b": "d"
}                 "c": null}      }
                }               }

{"a": [         {"a": [1]}      {"a": [1]}
  {"b":"c"}
 ]
}

["a","b"]       ["c","d"]       ["c","d"]

{"a":"b"}       ["c"]           ["c"]

{"a":"foo"}     null            null

{"a":"foo"}     "bar"           "bar"

{"e":null}      {"a":1}         {"e":null,
                                 "a":1}

[1,2]           {"a":"b",       {"a":"b"}
                 "c":null}

{}              {"a":            {"a":
                 {"bb":           {"bb":
                  {"ccc":          {}}}
                   null}}}

http://www.odata.org/をチェックしてください。

これはMERGEメソッドを定義しているので、あなたの場合は次のようになります：

MERGE /customer/123

<customer>
   <status>DISABLED</status>
</customer>

statusプロパティのみが更新され、他の値は保持されます。

それは問題ではありません。RESTに関しては、キャッシュできないためGETを実行できませんが、POSTまたはPATCHまたはPUTなどを使用するかどうか、およびURLがどのように表示されるかは関係ありません。RESTを実行している場合、重要なのは、サーバーからリソースの表現を取得するときに、その表現がクライアントの状態遷移オプションを提供できることです。

GET応答に状態遷移があった場合、クライアントはそれらを読み取る方法を知るだけでよく、サーバーは必要に応じてそれらを変更できます。ここでは、更新はPOSTを使用して行われますが、PATCHに変更された場合、またはURLが変更された場合でも、クライアントは更新方法を知っています。

{
  "customer" :
  {
  },
  "operations":
  [
    "update" : 
    {
      "method": "POST",
      "href": "https://server/customer/123/"
    }]
}

クライアントがあなたに返すために必要な/オプションのパラメータをリストするまで行くことができます。これはアプリケーションによって異なります。

事業運営に関する限り、それは顧客リソースからリンクされた別のリソースである可能性があります。顧客に電子メールを送信する場合、そのサービスはPOST可能な独自のリソースである可能性があるため、顧客リソースに次の操作を含めることができます。

"email":
{
  "method": "POST",
  "href": "http://server/emailservice/send?customer=1234"
}

いくつかの優れたビデオ、およびプレゼンターのRESTアーキテクチャの例はこれらです。StormpathはGET / POST / DELETEのみを使用します。RESTは、使用する操作やURLの外観（GETはキャッシュ可能であることを除く）とは何の関係もないため、問題ありません。

https://www.youtube.com/watch?v=pspy1H6A3FM、
https://www.youtube.com/watch?v=5WXYw4J4QOU、
http://docs.stormpath.com/rest/quickstart/