[Web開発者のWebサポート技術]-HSTP方法


👨🏻‍💻 8つの方法しかありません


メソッド意味GETリソース取得POSTサブリソースの作成、リソースデータの追加、その他の処理PUTリソースの更新.リソース作成DELETEリソースの削除HEADリソースの取得ヘッダ(メタデータ)OPTIONSリソースでサポートされているメソッドの取得TRACE自身が要求メッセージを返信(ロールバック)試験CONNECTエージェント操作のトンネル接続に変更する

👨🏻‍💻 HTTPメソッドとCRUD

  • CRUDとは?

  • 作成、読み込み、更新、削除
    CRUD名の未メソッド作成POST/POREAD読み出しGETUPdateリフレッシュPUTTDELETE削除DELETE
  • 👨🏻‍💻 GET-リソースの取得

  • 指定URIの情報を取得する.
  • 👨🏻‍💻 POST:リソースの作成、追加


    サーバリソースの作成

  • 任意のリソースを作成するサブリソース
  • 応答は201緊急状態コードを返す
  • リソースへのデータの追加

  • 既存リソース
  • にデータを追加
  • がリソースの最後にデータを追加するか、最初にデータを追加するかは、サーバの実装に依存する.
  • が最初から要求したPOSTは、サーバの実装に依存して、作成するか、データを追加するかを意味する.
  • 他の方法では処理できません

  • は理論的にURIの長さを制限しないが,実装上は2000文字の上限がある
    -URIが長い場合、POST要求は、GETメソッドと比較して、本体内のURIに含まれるキーワードとなる.
  • 👨🏻‍💻 PUT:リソースの更新、作成


    リソースの更新

  • リソースの変更を担当し、204 No Contentに戻ることができます.PUTの応答は結果をマスターに入れることができるか、204 Noに戻ることができます.応答にマスターが含まれていないことを示します.
  • リソースの作成


    存在しないURIに対してリクエストを発行すると、サーバは新しいリソースを作成します.
  • クライアントはすでにリソースのURIを知っており、位置ヘッダーに戻る必要はありません.
  • POSTとPUTの区分

  • 設計指導原則
    -POSTを使用してリソースを作成する場合
    -クライアントはリソースのURIを指定できず、URIの決定権はサーバ側
    -PUTを使用してリソースを作成します.
    -リソースのURIはクライアントによって決定される
    -リソースが重複して上書きされないように、クライアントが使用する前にURIの存在を確認する必要があります.
    -POSTでリソースを作成し、サーバ側でURIを決定することを推奨します.
  • 👨🏻‍💻 DELETE-リソースの削除

  • は、通常、応答主体を有しない.
  • 応答のSTATERSコードは、本体がないことを示す204 No Contentを使用する場合があります.
  • 👨🏻‍💻 HEAD-リソースタイトルの取得

  • リソースヘッダ(メタデータ)のみを取得する方法
  • ネットワーク帯域幅を節約しながら、リソースのサイズを調べたり、リソース更新係数を取得したりすることができます.
  • 👨🏻‍💻 OPTIONS-リソースサポートの取得方法

  • は、リソースによってサポートされるメソッドのリスト
  • を返す.
  • OPTIONS自体はAllow 헤더に含まれていない.
  • OPTIONSが実装される場合、多くのWebアプリケーションフレームワークは、各リソースに対応する方法を返すために直接実装されなければならない.プロファイルなどによる
  • // 요청
    OPTIONS /list HTTP/1.1
    
    //응답
    HTTP/1.1 200 OK
    Allow: GET, HEAD, POST // 리소스가 허용하는 메서드의 목록

    👨🏻‍💻 PUT/DELETEの代わりにPOSTを使用

  • で最も一般的な方法はGETとPOSTの2種類あります
  • HTMLフォームで指定できる方法は、
  • であるため、GETおよびPOSTに限定される.

    methodパラメータ

  • フォームの非表示パラメータにmethodというパラメータを用意し、メソッドの名前を元の送信先に配置します.
  • メソッドパラメータはRuby on Railsによって
  • を採用
    <form target="/List/item" action="POST">
    	<input type="hidden"id="_method"value="PUT">
    	<textrea id="body"> ... </textarea>
    </form>
    上記フォームを送信すると、次の要求が送信されます.
    POST /list/item1 HTTP/1.1
    Host: example.com
    Content-Type: application/x-www-form-urlencoded
    
    _method=PUT&body=...
  • 本体は、フォームに入力された内容をURIのクエリパラメータと同じspecに符号化するテキストを含む.
  • コンテンツタイプタイトルの値アプリケーション/x-www-form-urlcodedは、このフォーマットを表すメディアタイプです.
  • サーバ側インプリメンテーション(Webアプリケーションフレームワークなど)はmethodパラメータを表示し、この要求自体をPUTとして処理します.

    X-HTTP-Method-Override

  • アプリケーション/x-www-form-urlcoded以外のコンテンツタイプ.
  • GoogleのGDataはどのように
    POST /list/item1 HTTP/1.1
    Host: example.com
    Content-Type: application/xml; charset=utf-8
    X-HTTP-Method-Override: PUT
    
    <body> ... </body>
  • を採用します
    サーバ側インプリメンテーション(Webアプリケーションフレームワークなど)は、X-HTTPメソッドoverrideヘッダを表示し、この要求をPUTと見なす

    👨🏻‍💻 条件付きリクエスト


    条件付きリクエストとは?
    タイトルを
  • HTTPメソッドと更新日に設定することで、サーバはリソースの更新日に基づいてメソッドを実行するかどうかを選択できます.これらのリクエスト
  • 👨🏻‍💻 べき乗等性とセキュリティ


    通信エラーが発生した場合、リクエストをリカバリするにはどうすればいいですか?
    何が待っているのか.
  • 操作を何回も繰り返し、結果は同じです.
  • PUTとDELETEはべき乗等号であるため、同じリソース上で何度もPUTまたはDELETEを実行しても、同じ結果(リソースの内容が更新され、リソースが削除された):
  • を得る必要があります.
    セキュリティとは
  • 管理リソースの状態を変更しない
    方法性質GET、HEADべき乗等、安全PUT、DELETEべき乗等であるが、POSTべき乗等は安全ではなく、
  • も安全ではない.
  • リソースの状態を変更することを副作用と呼ぶ.安全→操作対象リソースに副作用なし
  • 👨🏻‍💻 方法の誤用

  • WebサービスとWeb APIが設計されていない場合、方法は安全ではないか、べき乗ではないなどになる可能性があります.
  • GET不安全例


    リソースを
  • GETに変更するか、リソースを削除するかはGETのエラー使い方
  • です.
  • GET実行前後にリソースが変更され、GETが正しく使用されているかどうかを確認
  • POSTの例を使用すると、他の方法を使用することができる。

  • の正しい方法があるにもかかわらず、POSTはどのようにその機能を実現するか
  • XML-RPCおよびSOAP
  • はRPCを実装するために設計されたプロトコルであるが、すべての関数呼び出しはPOST実装として設計されている.
  • PUTが非べき乗になる例

  • PUTが送信リソースコンテンツの相対差は
  • である.
  • PUTは、リソースの完全な表現を提供する.
  • DELETEがべき乗等でない例


    http://example.com/latestというailisリソースを削除します.
  • ソフトウェアの最新バージョンを示します.
  • の特殊なリソース(例えば、イリスリソース)は、他の理由がない限り、更新および削除などの操作を回避することを目的としている.
  • 👨🏻‍💻 Webの成功の原因はHTTPメソッドにある

  • メソッドが固定されているため,プロトコルは簡単に保たれ,Webは成功した.