agaviフレームワークは、PUTリクエストを使用して作成し、POSTを使用して情報を更新します。通常、RESTでは、これは逆に使用されます（多くの場合、POSTが情報を追加し、PUTがデータレコード全体を置き換えます）。
私がそれを正しく理解している場合、重要な問題は、PUTがべき等でなければならないということですが、POSTにはこの要件がありません。したがって、特にORMが主キーとしてIDを使用し、新しいレコードのIDがわからない場合は特に、新しいレコードの作成がべき等になる可能性があります（つまり、複数のリクエストがレコードの複数の作成につながることはありません）。クライアントに対して（データベースで自動作成されるため）、したがって、要求の一部にすることはできません。これに照らして、agaviはPUT要求のべき等の要件をどのように維持しますか。
ありがとう。
PUTは、完全なレコードの作成と更新の両方に使用できます。POSTは通常、部分的な更新と関連する操作、およびリソースのURLを指定せずにサーバー上に新しいタイプのレコードを作成するために使用されます（たとえば、/ articles / 23 /commentsへのPOSTは201ステータスと場所を返します：/ articles / 23 / comments / 283136ヘッダー）。したがって、（シーケンス/自動インクリメントIDを使用する）場合は、そのアプローチを使用します。
ただし、HTML（したがってWebフォーム）は異なります。GETとPOSTのみを認識し、DELETEとPUTは認識しません。削除および更新操作の場合、POSTメソッドをオーバーロードします。
そのため、Agaviはデフォルトで、POSTを「書き込み」にマップし、GETを「読み取り」にマップします。これは最も一般的な使用例であり、「読み取り」と「書き込み」は比較的中立であり、ある意味で安全性を表すために選択されました。 GETとPOSTの側面（「GETは副作用なしで呼び出すことができます」などの安全性）。
factorys.xmlでAgaviWebRequest実装の動詞のマッピングを変更できます。ヘルプが必要な場合は、AgaviユーザーのメーリングリストまたはIRCチャネルを参照してください（またはここで質問してください）。IRCチャネルの多くの人々は、APIをきれいにするためにさらに支援が必要な場合に備えて、URLスキームの設計にもかなりの経験があります。
PUT創造することとして考えるのではなく、それを「置くこと」として考えてください。リソースをURIに配置します（つまり、リソース全体をURIに送信します）。
PUT http://example.com/articles/1
これを繰り返す（同じリソース全体を同じURIに送信する）と、同じ結果が得られ、そのURIでリソースを変更していないため、べき等になります。
agaviのの実装がべき等である場合、正しくPUT実装されていPUTます。そうでなければそうではありません。
PUTを使用してリソースを作成できますが、リソースがすでに存在する場合（または以前のPUTによってすでに作成されている場合）は、リソースを更新するだけです。ただし、これが単純なCRUDの場合、POSTはリソースを更新しないでください。HTTP動詞は、CRUDだけでなく多くの場合に役立つため、必ずしも特定のアクションへのマッピングが定義されていないことに注意してください。
また、この質問はRESTとは関係がなく、適切なHTTPの使用法であることに注意してください。したがって、RESTタグを削除してください。
私は以前にこの問題を抱えていました。これは、factories.xmlを変更することで解決できます