ロストアップデート

ビジネスプロセスは、複数のクラウド API 呼び出しにわたることがよくあります。その場合、最初の呼び出しは、通常、データを取得する GET またはデータを作成する POST のいずれかになります。その後の呼び出しで、最初の GET または POST でクエリまたは作成されたリソースを変更しようとする場合があります。

その他のプロセスの中には、GET／POST と後続の変更を行う呼び出しとの間にリソースを変更できるものもあります。例えば、次のような場合があるとします。

呼び出し元アプリケーションがアクティビティ xc:20 を GET します。このアクティビティの件名は「その他の被保険者への連絡」で、優先度は標準です。
内部ユーザーが手動でアクティビティ xc:20 の件名を「主被保険者への連絡」に変更し、優先度を緊急に変更します。
呼び出し元アプリケーションがアクティビティ xc:20 に PATCH を実行し、優先度を低に設定します。

呼び出し元アプリケーションの PATCH では、内部ユーザーが行った変更の一部が上書きされます。次のいくつかの理由により、これが問題になる可能性があります。

呼び出し元アプリケーションによる変更は、最初に取得したデータに基づいて行われる場合があります。呼び出し元アプリケーションは、件名が既知のものであったり、優先度を後から誰かが変更していた場合には、変更を開始しないことがあります。
内部ユーザーは、その変更の一部が事実上廃棄されたことに気づかない場合があります。
アクティビティは、現在不整合な状態（通常は緊急のアクティビティに使用される件名なのに、優先度が低であるなど）になっている可能性があります。

このような変更をロストアップデートと呼びます。クラウド API では、ロストアップデートとは、その他のプロセスが行った変更を意図せずに上書きする、リソースへの変更です。チェックサムを使用することにより、ロストアップデートを回避することができます。