httpの重要な特性

1クライアント、サーバ構造を採用する。

メッセージを介してクライアントが要求を送信し,サーバが応答する構造.
これは、サーバにデータとロジックを集中させ、クライアントのURIと可用性を向上させるためです.
=>それぞれ独立した発展が可能となる.(フロントエンドとバックエンド)

2ステータス・プロトコルがありません。(stateless)

サーバはクライアントの状態を保持しません.サーバはクライアントを認識できず、ステータスを保持しません.これは、データを送信および受信するデータ要求が独立していることを意味します.すなわち、前のデータ要求は、次のデータ要求とは無関係である.
特長
-追加のセッション情報を管理する必要はありません.
-クライアント要求が急に増加しても、大量のサーバが必要になる場合があります.
-ステータスなしで応答サーバを簡単に変更できます.
-任意のサーバを任意に呼び出すことができます.
-水平拡張に有利です.
-1回の通信には多くのデータ量があります.
しかし、すべてのものが無償で設計できる可能性もあり、ない可能性もあります.
ex)
≪ステータスなし｜No Status｜ldap≫:ログイン・インタフェースの表示画面
≪ステータスの保持｜Keep Status｜ldap≫:サーバーのログイン状態を保持します.
リファレンス
-Cookieとセッションを使用してステータスを維持します.詳細については、HTTPヘッダセクション(サーバCookieはブラウザ、クライアント)を参照してください.

3非接続性

httpはクライアントとサーバが接続を確立した後、サーバの応答が完了し、すぐに接続を終了します.
Webの特性上、多くの人が同時にサービスを利用していますが、実際の処理の作業量は小さく、接続を維持し続けると大量のリソースが発生します.
=>これらのWebプロパティを考慮して、Httpはデフォルトで接続を維持しないモデルとして設計されています.
=>httpはサーバリソースを非常に効率的に使用します.
ex)検索操作

非接続性の限界を克服する

非永続接続HTTP
大量のリソース(HTML、JS、CSS、画像を含む)をダウンロードするたびに、接続/閉じる=>時間が必要です.
また、各リソースに新たなTCP/IP接続=>時間を追加する
HTTP接続の継続
TCP/IP接続を最初に維持し、クライアント/サーバが残りのリソースを要求/応答します.<=現在使用中
=>HTTP 2.0 3.0の最適化

HTTPメッセージ

スタートライン

リクエストメッセージstart-line=request-line
method SP request-target sp HTTP-version CRLF
方法:HTTP方法
request-target:絶対=path[?query]絶対パス[?クエリー]
HTTPバージョン:HTTPバージョン
SP: space
CRLF: enter
レスポンスメッセージstart-line=status-line
HTTP-version SP status-code SP reason-phrase CRLF
HTTPバージョン:HTTPバージョン
status-code:HTTP状態コード
reason-parrase:ステータスコードの記述文

見出し

header-field = field-name ":"OWS field-valu OWS
OWS:書き換え許可
ex)
Host: www.google.com
Content-Type: text/html;charset=UTF-8
ヘッダにはHTTP伝送に必要なすべての付加情報が含まれている

本体

実際に転送するデータ

HTTPメソッド

URI設計
=>uriリソースのみを識別
メソッド動作のみを識別
ex)
-リソースメンバー(名詞)
-変更動作の削除(動詞)

GETメソッド

リソースを問い合わせる.サーバに渡したいデータはquery(キュリー)で渡します.
メッセージ・ボディを使用してデータを転送できますが、サポートされていない場所が多いため、推奨されません.
注意:検索で使用し、セキュリティ保護を必要とせずに少量のデータを送信します.

POSTメソッド

要求データをサーバに転送します.サーバは、メッセージボディを介して受信したデータを処理します.多くの場合、データ変更、新しいリソース登録、プロセスなどのPOSTが使用されます.重要な部分は、データの作成、処理だけでなく、プロセスの処理にもあります.
ex)
1データ処理中にHTMLフォームに入力されたフィールドなどのデータブロックを提供する

HTML FORMに入力された情報は、会員登録、注文等に使用されます
2掲示板、ニュースグループ、メールリスト、ブログ、または類似のニュースグループにメッセージを公開

伝言板作文、伝言

3サーバがまだ確定していない新しいリソースの作成

新規メンバー

の作成
4既存のリソースへのデータの追加

文書の末尾にコンテンツを追加する

.
他の方法で処理することもあります.
POST要求は資源固有の体系に従って処理する.
POST/members HTTP/1.1
このように送信すると、サーバは指定されたシナリオに従ってプロセスまたは登録に使用されます.
たとえば、会員登録をしたい場合は
/members =>/members/100
サーバは独自のシステムに基づいて新しいリソース(100など)を作成し、JSONなどのファイルを生成します.応答データをクライアントに送信します.
注意:セキュリティ保護が必要な場合、大量のデータを送信する場合

PUTメソッド

簡単に説明しますが、ctrl+vと同じです.リソースを完全に置き換えます.リソース置換、リソース再生成なし
POSTとは異なり、クライアントはリソースを識別する.クライアントは、リソースの場所を認識し、URIを指定します.
PUT/members/100 HTTP/1.1(POSTとは異なる)
「リソースの完全な代替」
リソースを変更するわけではありません.

/members/100 (기존)
{
	"username":  "park",
	"age": 20
}

PUT /members/100 HTTP/1.1
/members/100 (전송)
{	
	"age": 50
}

/members/100 (대체)
{
	"age": 50
}

PATCH法

リソースを変更したい場合は、PATCHを使用します.

DELETEメソッド

リソースを削除する場合は、DELETEを使用します.

HTTPメソッドの属性

安全

GETとHEAD呼び出しはリソースを変更しません

襟元

同じリクエストを複数回送信
同じユーザが同じ動作に対してべき乗などである
正しく実装されるGET、PUT、DELETEメソッドは、べき乗等性を持たなければならない.
POSTはべき乗等ではない.

キャッシュ機能

応答結果はリソースをキャッシュおよび使用できますか?
GET、HEAD、POST、PATCHキャッシュ
実際には、GETとHEADのみがキャッシュとして使用されます
POST、PATCHは本明細書にキャッシュされることを考慮すべきであるが、実施は容易ではない

HTTPメソッドの利用

クライアントからサーバへのデータ転送

クエリー・パラメータによる送信
-GET:主にソートフィルタ
メッセージ本体からのデータ転送
-POST PUT PATCH:会員オーダーリソース登録リソースの変更

HTML Formデータ転送

静的データ・クエリー

画像、静的文書ドキュメント
常にリソースパスのみでクエリー

動的データ・クエリー

は主に検索に使用され、掲示板リストでソートフィルタ(検索語)を使用します.
クエリパラメータクエリ

を頻繁に使用

HTML Formによるデータ変更

Formフォームに従ってHTTPを生成して転送します.
主に会員の入金、商品の注文、データの変更を使用します
が存在します.
HTML =>
formでenctype=「multipart/form-data」を使用
HTTPヘッダ=>
Content-Typeプロパティはmultipart/form-dataです.boundar=--XXX(自動)
これは、所定のフォーマットで情報を符号化するためである.処理のためのサーバは、複数の部分メッセージを分離することによって、単一のファイルの情報を取得する
注意:HTML Form転送はGET、POSTのみサポート

HTTP APIの送信（Formを使用しない）

フォームなしで直接データを送信します.
-サーバからサーバへ
-アプリケーションクライアント
-Webクライアント
ex)Form転送ではなくHTMLでJavaスクリプトを使用して通信する(AJAX)
-POST、PUT、PATCH:メッセージ本体を通してデータを転送する
-GET:クエリー・パラメータへのデータ転送
コンテンツ-タイプ:主にアプリケーション/jsonに使用されます(実際には標準です).
リファレンス
持続/非持続接続
REST API
HTTP MDN
すべての開発者向けHTTPコース。