RESTで次のユースケースをどのように実装するのでしょうか。概念モデルを損なうことなく行うことさえ可能ですか？
単一のトランザクションのスコープ内で複数のリソースを読み取るか更新します。たとえば、ボブの銀行口座からジョンの口座に$ 100を転送します。
私の知る限り、これを実装する唯一の方法は不正行為です。JohnまたはBobのいずれかに関連付けられたリソースにPOSTし、単一のトランザクションを使用して操作全体を実行できます。私が懸念している限りでは、これはRESTアーキテクチャーを壊します。なぜなら、実際には個々のリソースを操作するのではなく、POSTを介してRPC呼び出しをトンネリングしているからです。
回答:
RESTfulな買い物かごのシナリオを考えてみましょう。買い物かごは、概念的にはトランザクションラッパーです。買い物かごに複数のアイテムを追加し、そのバスケットを送信して注文を処理するのと同じように、ボブのアカウントエントリをトランザクションラッパーに追加し、次にビルのアカウントエントリをラッパーに追加できます。すべてのピースが配置されたら、すべてのコンポーネントピースでトランザクションラッパーをPOST / PUTできます。
この質問では答えられないいくつかの重要なケースがありますが、Googleでは検索語のランキングが高いため、これは残念です。
具体的には、適切なのは次のとおりです。POSTを2回実行する場合（中間キャッシュで一部のキャッシュが占有されるため）、2回転送しないでください。
これを行うには、トランザクションをオブジェクトとして作成します。これには、すでに知っているすべてのデータが含まれ、トランザクションを保留状態にすることができます。
POST /transfer/txn
{"source":"john's account", "destination":"bob's account", "amount":10}
{"id":"/transfer/txn/12345", "state":"pending", "source":...}
このトランザクションを取得したら、次のようにコミットできます。
PUT /transfer/txn/12345
{"id":"/transfer/txn/12345", "state":"committed", ...}
{"id":"/transfer/txn/12345", "state":"committed", ...}
この時点では、複数のプットは関係ありません。txnでGETを実行しても、現在の状態が返されます。具体的には、2番目のPUTは、最初のPUTがすでに適切な状態にあることを検出し、それを単に返します。または、すでに「コミット済み」状態になっている後に「ロールバック」状態にしようとすると、エラー、および実際にコミットされたトランザクションが戻されます。
単一のデータベース、またはトランザクションモニターが統合されたデータベースと通信する限り、このメカニズムは実際には問題なく機能します。さらに、トランザクションのタイムアウトを導入することもできます。タイムアウトは、必要に応じてExpiresヘッダーを使用して表現することもできます。
RESTの用語では、リソースはCRUD（作成/読み取り/更新/削除）動詞で処理できる名詞です。「送金」動詞はないため、CRUDで処理できる「トランザクション」リソースを定義する必要があります。これはHTTP + POXの例です。最初のステップは、することですCREATE（HTTP POSTメソッド）新しい空のトランザクションを：
POST /transaction
これは、「1234」などのトランザクションIDと、それに対応するURL「/ transaction / 1234」を返します。このPOSTを複数回起動しても、複数のIDを持つ同じトランザクションは作成されず、「保留中」の状態の導入も回避されることに注意してください。また、POSTは常にべき等であるとは限らないため（REST要件）、POST内のデータを最小限に抑えることをお勧めします。
トランザクションIDの生成はクライアントに任せることができます。この場合、POST / transaction / 1234を実行してトランザクション「1234」を作成し、サーバーがすでに存在する場合はエラーを返します。エラーレスポンスでは、サーバーは現在使用されていないIDと適切なURLを返す可能性があります。GETはサーバーの状態を決して変更しないため、GETメソッドでサーバーに新しいIDを照会することはお勧めできません。新しいIDを作成または予約するとサーバーの状態が変更されます。
次に、トランザクションをすべてのデータで更新（PUT HTTPメソッド）し、暗黙的にコミットします。
PUT /transaction/1234
<transaction>
<from>/account/john</from>
<to>/account/bob</to>
<amount>100</amount>
</transaction>
ID "1234"のトランザクションが以前にPUTされた場合、サーバーはエラー応答を返します。それ以外の場合、OK応答と完了したトランザクションを表示するためのURLを返します。
注：/ account / johnでは、「john」は実際にはJohnの一意のアカウント番号である必要があります。
すばらしい質問です。RESTのほとんどは、データベースのような例で説明されています。ここでは、何かが保存、更新、取得、削除されます。この例のように、サーバーが何らかの方法でデータを処理することになっている例はほとんどありません。ロイ・フィールディングが彼の論文に何も含まなかったと私は思う。結局のところ、それはhttpに基づいていた。
しかし彼は、リンクを次の状態に移動させて、状態マシンとしての「表現状態転送」について話します。このようにして、サーバーがクライアントの状態を追跡する代わりに、ドキュメント（表現）がクライアントの状態を追跡します。このように、クライアントの状態はありません。現在のリンクに関する状態のみが示されます。
私はこれについて考えていましたが、サーバーに何かを処理させるために、アップロードすると、サーバーが関連リソースを自動的に作成し、それらへのリンクを提供することは理にかなっているようです（実際には、それらを自動的に作成する必要はありません。リンクを通知するだけで、フォローした場合にのみリンクを作成します-遅延作成）。また、新しい関連リソースを作成するためのリンクも提供します-関連リソースは同じURIを持ちますが、長くなります（サフィックスが追加されます）。例えば：
/transaction
グリッチにより、それぞれが異なるURIを持つ複数のリソースが作成されます。/transaction/1234/proposed、 /transaction/1234/committedこれはWebページの動作に似ており、最後のWebページには「これを実行してもよろしいですか？」その最終的なWebページは、それ自体がトランザクションの状態の表現であり、次の状態に進むためのリンクが含まれています。金融取引だけではありません。また（例えば）プレビューしてからウィキペディアでコミットします。RESTの違いは、状態のシーケンスの各ステージに明示的な名前（URI）があることです。
実際のトランザクション/販売では、トランザクションのさまざまな段階（提案、発注書、受領書など）ごとに異なる物理的なドキュメントが存在することがよくあります。家の購入、決済などにさらに役立ちます。
OTOHこれは私にとってセマンティクスで遊んでいるような気がします。「動詞（RPC呼び出し）の代わりに名詞（URI）を使用するため」動詞を名詞に変換してRESTfulにする名詞化には不快です。つまり、「commit this transaction」という動詞の代わりに、「committed transaction resource」という名詞。名義化の利点の1つは、リソースを名前で参照できることです。リソースを他の方法で指定する必要はありません（たとえば、セッション状態を維持するため、「この」トランザクションが何であるかがわかります）。
しかし重要な質問は次のとおりです。このアプローチの利点は何ですか？つまり、このRESTスタイルはRPCスタイルよりもどのように優れていますか？Webページに最適な手法は、保存/取得/更新/削除以外に、情報の処理にも役立ちますか？RESTの主な利点はスケーラビリティだと思います。その1つの側面は、クライアントの状態を明示的に維持する必要がないことです（ただし、リソースのURIでそれを暗黙的にし、次の状態をその表現のリンクとして）。その意味で役立ちます。おそらくこれはレイヤー化/パイプライン化にも役立ちますか？OTOHは1人のユーザーだけが特定のトランザクションを見るので、それをキャッシュしても他のユーザーが読み取れるという利点はなく、httpの大きな利点です。
ここでの議論を要約すると、RESTは多くのAPIには適切ではないことは明らかです。それは、クライアントサーバーの対話が本質的にステートフルであり、重要なトランザクションの場合と同様です。クライアントとサーバーの両方について、問題に適合しないいくつかの原則に徹底的に従うために、提案されているすべてのフープをジャンプするのはなぜですか？より良い原則は、アプリケーションを構成する最も簡単で自然で生産的な方法をクライアントに提供することです。
要約すると、実際にアプリケーションで多くのトランザクション（インスタンスではなくタイプ）を実行している場合、RESTful APIを作成するべきではありません。
私はこのトピックから10年間離れていました。戻って、私はあなたがグーグル休憩+信頼できるときにあなたが踏み込む科学になりすました宗教を信じることができません。混乱は神話です。
この幅広い質問を3つに分けます。
あなたの要件は基本的なものです。あなたの解決策がユダヤではないとあなたに言わせてはいけません。彼らがあなたの問題にどれだけうまく、そしてどれほど簡単に対処しているかに照らして、彼らのアーキテクチャを判断してください。
独自の「トランザクションID」タイプのトランザクション管理をロールする必要があります。したがって、4つの呼び出しになります。
http://service/transaction (some sort of tx request)
http://service/bankaccount/bob (give tx id)
http://service/bankaccount/john (give tx id)
http://service/transaction (request to commit)
アクションの格納をDB（負荷分散されている場合）またはメモリなどに処理してから、コミット、ロールバック、タイムアウトを処理する必要があります。
本当に公園でのRESTfulな日ではありません。
まず、送金は、1回のリソース呼び出しで実行できないことではありません。あなたがしたい行動は送金です。したがって、送金者のアカウントに送金リソースを追加します。
POST: accounts/alice, new Transfer {target:"BOB", abmount:100, currency:"CHF"}.
できました。これはアトミックである必要があるトランザクションであることを知る必要はありません。単に送金を別名で行うだけです。AからBに送金します。
しかし、ここではまれなケースの一般的な解決策：
定義されたコンテキストで多くのリソースを必要とする非常に複雑なことをしたい場合は、実際にwhatとwhyの障壁（ビジネスと実装の知識）を越える多くの制限があり、状態を転送する必要があります。RESTはステートレスである必要があるため、クライアントとしての状態を転送する必要があります。
状態を転送する場合、内部の情報をクライアントから隠す必要があります。クライアントは、実装にのみ必要な内部情報を知っているべきではありませんが、ビジネスの観点から関連する情報を持ちません。これらの情報にビジネス上の価値がない場合は、状態を暗号化し、トークン、パスなどのメタファーを使用する必要があります。
このようにして、内部状態を渡し、暗号化と署名を使用して、システムを安全かつ確実にすることができます。クライアントが状態情報を渡す理由をクライアントに適切に抽象化することは、設計とアーキテクチャ次第です。
実際のソリューション：
RESTはHTTPを話し、HTTPにはCookieを使用するという概念が付属していることを思い出してください。それらのCookieは、人々がREST APIとワークフロー、および複数のリソースまたはリクエストにまたがる相互作用について話すとき、しばしば忘れられます。
ウィキペディアでHTTP Cookieについて書かれていることを思い出してください。
Cookieは、Webサイトがステートフルな情報（ショッピングカート内のアイテムなど）を記憶したり、ユーザーの閲覧アクティビティ（特定のボタンのクリック、ログイン、ユーザーがアクセスしたページの記録など）を記録したりするための信頼できるメカニズムとして設計されました数か月または数年前に戻します）。
したがって、基本的に状態を渡す必要がある場合は、Cookieを使用します。それはまったく同じ理由で設計されています。それはHTTPであり、したがって設計によりRESTと互換性があります:)。
より良い解決策：
複数のリクエストを含むワークフローを実行するクライアントについて話す場合、通常はプロトコルについて話します。すべてのプロトコル形式には、Bを実行する前にステップAを実行するなど、潜在的なステップごとに一連の前提条件が付属しています。
これは自然なことですが、クライアントにプロトコルを公開すると、すべてがより複雑になります。それを避けるために、現実の世界で複雑な相互作用やことをしなければならないときに私たちが何をすべきかを考えてください。エージェントを使用します。
エージェントのメタファーを使用すると、必要なすべての手順を実行できるリソースを提供し、実際の割り当て/それが実行されている指示をリストに格納できます（そのため、エージェントまたは「代理店」でPOSTを使用できます）。
複雑な例：
家を買う：
信頼性を証明する必要があります（警察の記録を提供するなど）、財務の詳細を確認する必要があります。弁護士と資金を保管している信頼できるサードパーティを使用して実際の家を購入し、家が自分のものであることを確認する必要があります。税務記録などに購入用のものを追加します（例として、いくつかの手順は間違っているか、または何でもかまいません）。
これらの手順は完了するまでに数日かかる場合があります。並行して実行できる手順もあります。
これを行うには、次のようにエージェントにタスク購入ハウスを与えるだけです。
POST: agency.com/ { task: "buy house", target:"link:toHouse", credibilities:"IamMe"}.
できました。代理店は、このジョブのステータスを確認および追跡するために使用できる参照をあなたに送り返します。残りは代理店のエージェントによって自動的に行われます。
たとえば、バグトラッカーについて考えてみましょう。基本的にはバグを報告し、バグIDを使用して何が起こっているかを確認できます。サービスを使用して、このリソースの変更をリッスンすることもできます。ミッション完了。
RESTではサーバー側トランザクションを使用しないでください。
REST制約の1つ：
ステートレス
クライアントとサーバーの通信は、リクエスト間でサーバーにクライアントコンテキストが保存されないことによってさらに制約されます。クライアントからの各要求には、要求を処理するために必要なすべての情報が含まれており、セッション状態はクライアントで保持されます。
RESTfulな唯一の方法は、トランザクションREDOログを作成してクライアント状態にすることです。リクエストにより、クライアントはREDOログを送信し、サーバーはトランザクションを再実行し、
しかし、サーバー側のトランザクションをサポートするサーバーセッションベースのテクノロジーを使用する方が簡単な場合があります。
これは、クライアントで生成された一意の識別子を使用して、接続の中断がAPIによって保存された重複を意味しないことを保証する場合に当てはまると思います。
クライアントで生成されたGUIDフィールドを転送オブジェクトと共に使用し、同じGUIDが再度挿入されないようにすることは、銀行振込の問題に対するより簡単な解決策になると思います。
複数の航空券予約やマイクロアーキテクチャなど、より複雑なシナリオについては知らない。
RESTfulサービスでトランザクションの原子性を処理する経験に関連する、この件に関する論文を見つけました。
単純な場合（分散リソースなし）では、トランザクションをリソースと見なすことができ、トランザクションを作成することで最終目的が達成されます。
したがって、との間<url-base>/account/aで転送<url-base>/account/bするには、以下にを投稿できます<url-base>/transfer。
<乗り換え>
<from> <url-base> / account / a </ from>
<to> <url-base> / account / b </ to>
<amount> 50 </ amount>
</転送>
これにより、たとえば新しい転送リソースが作成され、転送の新しいURLが返されます<url-base>/transfer/256。
投稿が成功した時点で、サーバー上で「実際の」トランザクションが実行され、金額が1つのアカウントから削除され、別のアカウントに追加されます。
ただし、これは分散トランザクションをカバーしていません（たとえば、「a」が1つのサービスの背後にある1つの銀行で保持され、「b」が別のサービスの背後で別の銀行で保持されている場合）-「すべてをフレーズしてみてください分散トランザクションを必要としない方法での操作」。
URL /リソースにTANを含めることができると思います：
ただのアイデア。