Achievement Goals

🍎 クライアント-サーバの概念を理解します.
-HTTPを使用するクライアントについて-サーバ通信.
-APIの概念を理解することができる.
🍎 HTTPメッセージの構造を記述することができる.
-HTTPの動作が理解できる.
-HTTPリクエストとレスポンスを区別できます.
-HTTPの応答メッセージを表示できます.

1.通信要求プロセス

    클라이언트   <->        서버      <->   데이터베이스
리소스 사용하는 앱 <-> 리소스 전달해주는 앱 <-> 리소스 저장공간

私たちが喫茶店でコーヒーを注文したとき、コーヒーのように(答え)
サーバが応答するのは、クライアントが要求した場合にのみです.
クライアントとサーバの間でHTTPプロトコルを使用して通信します.
HTTPでやりとりされるメッセージを「HTTPメッセージ」と呼ぶ.

ex) GET /americano HTTP/1.1 Host:starbucks.com (요청)
    HTTP/1.1 200 ok { "data" : "americano" }   (응답)

(1)プロトコルとは?

コンピュータ上のプロトコルは規則であり、約束された用語である.
つまり、クライアントは、サーバに要求を送信するときにルールに従って注文する必要があります.これにより、サーバが理解でき、要求するときに守らなければならないプロトコルはさまざまです.

🤓 周辺のプロトコルの例

(1)直接カフェに行ってサーバーに注文する.|移動/アラームによる注文|ジオスクで注文.
(2)配送する場合は、宅配会社が正確な情報を受け取ることができるように、正しい住所を入力してください.

(2)プロトコルタイプ

👉 アプリケーション層

HTTP:HTML、JSON情報をWeb上で交換するプロトコル
HTTPS:HTTPにおけるセキュリティ強化プロトコル
FTP:ファイル転送プロトコル
SMTP:メール送信のためのプロトコル
SSH:CLI環境に接続するためのリモートコンピュータのプロトコル
RDP:Windowsシリーズのリモートコンピュータに接続するためのプロトコル
WebSocket:リアルタイム通信、プッシュなどのプロトコルをサポート

👉 でんそう

TCP:HTTP、FTP通信基盤の双方向インターネットプロトコル
UDP:一方的な作業.より簡単で、速度は速いが、信頼性は低い.

(3) API

しかし、クライアントはこれらのプロトコルのルールをどのように利用してサーバに要求しますか?
カフェにはアメニティからサイダーまでのメニューがたくさんあります.
アプリケーションプログラミングインタフェース(API)がメニューとして機能するメニューが表示され、サーバまたはセルフ注文およびリクエストが実行されます.
サーバにとって、クライアントは正しいAPIドキュメントを作成してこそ、正しい情報を使用することができます.通常、HTTPプロトコルアクセスアドレス(URL、URI)を要求することができる.

https://example.com/over/there? 
// The question mark is used as a separator
name=ferrethttps://example.com/path/to/page?name=ferret&color=purple

正しいメニューと対応するオプションをパラメータと呼びます.
このラテは?わあ&記号を使います.

（4）HTTP API方法

GET:照会(read)
POST:追加(作成)
PUTまたはPATCH:更新
DELETE:削除(delete)

HTTPとは?

HTTP(HyperText Transfer Protocol)は、HTMLなどの文書を転送するためのプロトコルである.
クライアントがHTTPメッセージ形式で要求を送信すると、サーバもHTTPメッセージ形式で応答する.
HTTPは無状態であり、特定の状態を保持しない特性を有する.

(1)無状態

状態がないのはどういう意味ですか?
クライアントとサーバが通信している間、HTTPは双方の状態を個別にチェックしません.
例えば、私たちがネットで買い物をする過程を考えてみましょう.
ログイン->商品をクリック->詳細ページ->カートを含む...などなど.
HTTP通信は、ユーザ(クライアント)が実行するこれらの動作を単独で追跡または保存しない.HTTPは通信プロトコル、つまり規約にすぎないからです.ステータスを確認する方法としてAPI、Cookieなどがあります.

(2) HTTP messages

前述したように、クライアントとサーバの間でリクエストと応答でデータをやり取りする際に使用されるルール・フォーム.
HTTPメッセージは、プロファイル、API、その他のインタフェースで自動的に完了するため、自分で作成する必要はありませんが、次のコンポーネントで構成されていることを確認してください.

👉 start line:リクエストと応答の状態を表す常に最初の行にあります.
👉 HTTPヘッダ:メッセージ本文を要求または記述するヘッダの集合を指定します.
👉 空白行:タイトルとボディの間の空白行
👉 body:リクエストと応答に関連するデータが含まれます.リクエストとレスポンスのタイプによってはオプションです.
startle+HTTPヘッダ=レスポンスヘッダ
body=ペイロード(転送データ)

3.要求と応答

(1)要求

HTTPリクエストはクライアントがサーバに送信するメッセージである.

start lineの3つの要素

👉 実行方法を説明する方法が作成されます.(GEP,POST,PUT..)
👉 要求先またはプロトコル、ポート、ドメイン(例えばURL/URI)の絶対パスは、要求コンテキストで作成され、HTTPメソッドによって異なる.

ソースフォーマット:?クエリー文字列の絶対パス(GEP、POST、HEAD、OPTIONSなどのメソッドとともに使用)

絶対フォーマット:完全なURLフォーマットで記述され、ほとんどはGETとともに使用されます.

権威タイプ:URLの権威コンポーネント(ドメインとポートからなる).HTTPトンネルを構築する場合、CONNECTと連携して使用できます.

アスタリスク形式:サーバー全体をOPTIONSと*記号で表します.

👉 HTTPバージョンはメッセージの構造を決めるので、バージョンも一緒に入力します.

Headers値の3つのグループ

リクエストのHeadersは、大文字と小文字を区別しない文字列、コロン(:)、入力値のデフォルト構造に従います.
値はヘッダーによって大きく3つに分けられます.

👉 要求ヘッダー:User-Agent、Accept-Type、Accept-Languageのように、ヘッダーは要求を具体化します.コンテキストを指定したり、コンストレイントを追加したりできます.
👉 General Headers:メッセージ全体に適用されます.
👉 タイトル:タイトル(Content-Loengthなど)はbodyに適用されます.bodyが空の場合、この部分は転送されません.

Bodyの2種類

リクエスト中のbodyは、サーバにリソースをリクエストするときに必要ありません.ただし、POST、PUT等の要求方法があれば、データの更新に用いる.
👉 単一リソースボディ:タイトル内のコンテンツタイプ、コンテンツ長として定義された2つの単一ファイルから構成されます.
👉 ≪マルチリソース・マスター｜Multi Resource Master｜oem_src≫:複数のセクションからなるマスターでは、各セクションに異なる情報があり、通常はHTMLフォームに関連しています.

(2)応答

HTTP応答の開始行startではなく状態を表すstatus line.

status lineの3つの要素

👉 現在のプロトコルのバージョン(HTTP/1.1)
👉 要求結果を示すステータスコード(200302404.)
👉 ステータスコードの説明を示すステータステキスト.

Headers

リクエストヘッダと同じ構造で、値によって3つのグループに分けられます.

👉 Request Headers:ステータスラインに入れるには不十分なその他の情報を提供します.(Vary, Accept-Ranges)
👉 タイトル:タイトル(Content-Loengthなど)はbodyに適用されます.bodyが空の場合、この部分は転送されません.
👉 General Headers:メッセージ全体に適用されます.

Bodyの2種類

HTTPメッセージの最後にあり、リクエストと同様にすべての応答が必要とされるわけではありません.
👉 単一リソースボディ:タイトル内のコンテンツタイプ、コンテンツ長として定義された2つの単一ファイルから構成されます.また、長さを知らない単一のファイルからなる単一のリソースボディは、トランスポート側符号化ブロックとして設定され、ファイルはブロックとして符号化される.
△実は、この部分がどういう意味なのか理解できないので、MDNの基準に従って伝播します.
👉 ≪マルチリソース|Multi Resource|emdw≫:異なる情報を含むマルチリソース.