問題タブ [httpverbs]

ストレートな html ハイパーリンクで送信できる GET 以外の動詞はありますか?

HTMLハイパーリンクがGETメソッドのみを使用する理由を説明しているドキュメントを知っていますか?

OData と Knockout Js を使用しているアプリケーションがあります。私のアプリケーションでは、POST、GET、および DELETE HTTP 動詞を使用しています。アプリケーションをホストしたときに、GET と POST はエラーをスローしませんが、DELETE はエラーをスローし、修正方法がわかりません。

以下は、DELETEを使用している場所です

そして、エラーは

どうすれば修正できますか

REST に関するこのプレゼンテーション(タイムスタンプ 17:00-18:45) で、講演者は、HTTPPUTにはリソースのすべてのプロパティを含める必要があり、部分的な更新には使用しないと述べています。これは HTTP で必要です。それ以外の場合はべき等ではありません。

彼の冪等性の定義は次のとおりです (これは合理的に聞こえます)。

べき等とは、1 回または複数回実行でき、同じサーバー状態になる操作です。

ただし、彼は次に例を挙げます (言い換えると):

リクエスト A: を使用しPUTて、リソースの name プロパティのみを更新します。

リクエスト B: a を使用しPUTて、説明のみを更新します。

A と B の間で別のクライアントが名前を指定でき、要求 B の後、リソースには他のクライアントの名前と私の説明が含まれます。リクエスト A と B の後でサーバーの状態が同じではないため、これはべき等操作ではありません。

この解釈についてはよくわかりません。私にとって、冪等性は、同じ操作を連続して複数回実行したときに何が起こるかについてのみ教えてくれます。上記の例では、リクエスト A と B は 2 つの異なる操作であるため、A を実行してから B を実行しても特別な保証が必要であると考える理由はありません。特に、それらが一緒になってアトミック操作を構成する必要があると考える理由はありません。

リクエスト A を複数回実行すると、(B の場合も同様に) 1 回実行するのと同じ効果が得られるため、(これがPUT他の理由での不適切な使用であったとしても) 冪等であると考えたでしょう。

私の理解は間違っていますか？

(注: これはべき等性の意味に関する質問であり、 の適切な使用法ではありませんPUT)。

アカウントにキャラクターがいるゲームのウェブサイトを開発しています。私はルートを使用しています：

しかし、私は(それらはソフト削除された) 文字を使用する必要がdeleteあり、フォームを使用するのは正しい方法ですが、. また、削除を取り消す/復元するための動詞はありません。undeletedeletecharacter/{name}/delete

これを回避するための正しくて簡単な方法 (または完璧な方法がない場合はその両方) は何ですか?

どのようにデータを送信するか、または DELETE HTTP 動詞を介して URL に送信するか、それによって何が得られ、ブラウザのサポートについてはどうですか?

ありがとう、

PUT はべき等ですが、POST はそうではありません。「チームに追加」タイプのメソッドがあるとしましょう。指定されたチームにまだ参加していない場合は、追加されます。すでにチームに参加している場合は、何も起こりません。

したがって、これは POST ではなく PUT であるべきだと考えています。1 回呼び出しても、100 万回呼び出しても、サーバー上の結果は同じだからです。あなたはチームにいます。

これは正しい考えですか、それとも私はまだ混乱していますか?

これは非常に基本的な質問のように思われるため、以前に尋ねられた場合は申し訳ありません。有用なリソースの方向を教えてください。

したがって、データを取得するための RESTful サービスがあります。ただし、RESTful サービスでは、取得を行うために一定量のデータが必要です。このデータは、「ユーザー コンテキスト」データとして大まかに要約できます。ユーザーに関する情報 (呼び出し元のアプリケーションによって保存されているか、以前に別のアプリケーションから取得されたか) は、サービスが取得を実行するために使用する必要があります。

REST は意味的に機能するため、何かを取得するための正しい動詞 (HTTP メソッド) は GET 要求です。私が見たほとんどの GET リクエストの例は、少量のデータしか使用せず、データは URL で渡されます。しかし、検索するために大量のデータを必要とするサービスの領域に入ると、そのすべての情報を URL に入れるのは間違っているように思えます。それだけでなく、特定のコンポーネント (多くの場合 255 文字程度、IIRC) によって適用される URL の長さには既知の制限があります。

利用可能なオプションは次のようです。

• POST を使用して、要求本文でデータを送信します。ただし、サービスに何も更新することを要求しておらず、取得のみを要求しているため、これはセマンティックではありません。
• 情報の大部分 (私の場合は「ユーザー コンテキスト」) を HTTP ヘッダーに入れます。ただし、ヘッダーはデータではなくヘッダーに使用する必要があるため、これは「間違っていると感じます」。
• 複数の URL でデータを送信する複数の要求を行います。ただし、サービスはリクエストを結び付けるために何らかの状態を維持する必要があるため、これはステートレスの目標を破るようです。
• データをデータベースに書き込み、サービスにキーを渡してそこからデータを取得します。ただし、これにより、要求が自己完結型ではなくなり、パフォーマンスのボトルネックも発生します。

別のオプションはありますか？ここでのベストプラクティスは何ですか?