「Response.PermanentRedirect」を利用する場合
別の場所への永続的なリダイレクトを意味する Http 応答コード 301 が返されます。これは、ブラウザーを使用するエンド ユーザーにとっては何の価値もないかもしれませんが、検索エンジンにとっては、検索エンジンが永続的にリダイレクトされた URL をインデックスに登録しないようにするのに役立ちます。
質問- Delete VerbMVC で同じ機能を実行しますか?
URI への追加として新しいエンティティを投稿します。PutURI で識別されるエンティティを置き換えます。
質問- 挿入/更新を実行すると、両方のケースで情報が送信されます。Insert の場合は をPost verb使用し、Update の場合は をPut verb使用する必要があるということですか?
最初の質問に答えるには:
RESTful API の観点からすると、多くの場合コレクションまたはストアである親からリソースを削除するには、DELETE を使用する必要があります。特定のリソースに対して DELETE 要求が処理されると、クライアントはそのリソースを見つけることができなくなります。したがって、今後、GET または HEAD を使用してリソースの状態表現を取得しようとすると、API によって 404 (「Not Found」) ステータスが返される必要があります。
DELETE メソッドには HTTP の非常に特殊なセマンティクスがあり、REST API の設計によってオーバーロードしたり拡張したりしてはなりません。具体的には、API は、リソースとその URI をクライアントが利用できるようにする、より少ないアクションに DELETE をマッピングすることによって、DELETE の意図された意味を歪めるべきではありません。
204 (「No Content」) は、PUT、POST、または DELETE 要求への応答で使用する必要があります
Response.PermanentRedirect は、REST API のリソース モデルが大幅に再設計され、新しい永続 URI がクライアントの要求されたリソースに割り当てられたことを示します。REST API は、応答のLocationヘッダーで新しい URI を指定する必要があります。
リソースの再配置には 301 (「Moved Permanently」) を使用する必要があります
Post と Put の場合:
PUT は、クライアントによって指定された URI を使用して新しいリソースを追加するために使用する必要があり、既に保存されているリソースを更新または置換するためにも使用する必要があります。PUT は可変リソースの更新にも使用する必要があり、POST はコレクション内に新しいリソースを作成するために使用する必要があります。