RESTサービスを介してインボイス機能を提供するRESTサービスがあります。たとえば、RESTサービスを使用してインボイスを作成、更新、削除することができます。リソースのRESTfulマージと分割
ただし、請求書を複数の新しい請求書に分割する機能が必要です。つまり、1つの請求書に基づいてx請求書を作成し、元の請求書を1つのトランザクションで削除する必要があります。
また、反対の、つまり複数の請求書が1つにマージされるマージメソッドが必要です。
RESTfulな方法でそのようなアーキテクトを作成するにはどうすればよいですか？
私たちは2つのリソースをマージしたいという同様の問題がありました。長い議論の末、コンシューマがマージする2つのリソースを含むマージリクエストリソースをPOSTすることにしました。それを見てから、完全なソースとターゲットリソースの両方を必要とせず、一意のIDのPOSTだけで十分であると判断しました。私たちは、2つの身分証明書だけが身体に入った状態で併合要求を出しませんでした。 URLで表現する方が簡単でしたので、これが私たちの行いでした。マージ要求のPOSTからの応答は、マージされたリソースです。
私はこれが良い戦略であるかどうかを伝えるのに十分なRESTの指導者ではないと思いますが、私たちにとっては簡単な解決策でしたので、
「1つのトランザクション」でこの機能を実装したいと思う場合は、新しい請求書の生成と古いものの削除を1つのAPI呼び出しに結合する必要があると判断したと仮定します。これは正しいアプローチです。 Webサービスでは、チャタリングを減らしたいと思います。この機能が新しい請求書を生成し、古い請求書を削除する方法に関するビジネスロジックがおそらく存在します。そこで、この新しいAPIメソッドにどのHTTP動詞（GET、POST、PUT、DELETE）を使用するのか不思議に思うRESTfulな方法でこれをどのように構築するかを尋ねるとき、私は仮定しています。通常、これらの動詞は、次のようにCRUDタイプの操作にマップ：
あなたの関数がレコードを作成したり削除したりするときに使う動詞。 REST APIの一般的なルールは、CRUDへの明確なマッピングがない場合に、サーバーの状態が変更された場合はPOSTを使用し、サーバーの状態を変更しない情報を返す場合はGETを使用します。この場合、私はPOSTと一緒に行くだろう。
建築に関する追加のガイダンスをお探しの場合は、より具体的なものをお探しください。お手伝いをします。私のような何かをするだろう
、
POST /InvoiceSplitter?sourceInvoiceId=99
と
POST /InvoiceMerger?sourceInvoiceIds=101,87,23,45
これらのURLは、URLパスではなくIDによってリソースを識別すると、特に安心して見えません。私は 'POST/path/to/invoice/99？split = true'や' POST/path/to/invoice/99？mergeWith =/path/to/invoice/101'のようなことをします。 –
@AlexanderKlimetschek RESTfulなURLはありません。私は、HTTP仕様で定義されている "処理リソース"という概念を使用しています。あなたの例も大丈夫です。ただし、クエリ文字列パラメータの値をスラッシュからエスケープしてください。 –
こんにちはケビン、あなたはURLが操作をマージこれらの分割/のためのようになりますどのように提案することができますか？ –