今月から、フロントエンドの学習に入る。
2021年1月から受講していたRaiseTechのAWSコースは一通り終わったものの、まだあとでやることリストはたんまり残っている。(AWSの記念すべき第1回目の記事は、Rubyのインストールだった！懐かしい・・・)
が、自分の学習の目的は、幅広い分野を「まずは知る(気になったときに調べることができる基礎を作る)」ことなので、AWSのToDoもゆるゆるやりつつ、次へ進んでいくことにする。
フロントエンド学習にあたり、今回もRaiseTechのReactコースを受講することにした。
この講座が終わるころには、「フロントエンド」という概念について腹落ちしていることを祈りたいｗ
フロントエンドとは？
Wiki先生によると、
ソフトウェア設計におけるフロントエンドは、ユーザーと直接やりとりするソフトウェアシステムの部分を指し、バックエンドはフロントエンドへの出力を生成する部分を指す。ソフトウェアシステムをフロントエンドとバックエンドに分けることは一種の抽象化であり、システムを異なる部分に分離して扱いやすくする効果がある。
ということらしい。
ふむ・・・。わかったようなわからないような。(つまりわからないｗ)
ざっくりまとめるとこういう感じかな・・・
- フロントエンドはユーザーから見えるが、バックエンドはユーザーからは見えない
- ユーザーと直接やり取りをするのがフロントエンド、フロントエンドからのデータをもとに処理をして結果を出力したり情報を保存したりするのがバックエンド
- フロントエンドはクライアントサイド、バックエンドはサーバーサイドとも呼ばれる
- フロントエンドの開発で主に利用される言語はHTML/CSS、JavaScript
- バックエンドの開発で主に利用される言語はJava、JavaScript、PHP、Python、Ruby
APIとは？
APIは「Application Programing Interface」の略。
名前の通り、ソフトウェア同士をつなぐインターフェース。
ここでもWiki先生が非常にわかりやすい説明をしてくれているので引用。
APIは各種システム／サービスがそのシステム／サービスを利用するアプリケーションに対して公開するインタフェースである。APIの重要な役割は、システム／サービス提供者が公式に仕様（外部仕様）を定義し、管理している各種機能を利用するための操作方法（インタフェース）を提供することである。APIは多くの場合、アプリケーションを構築する言語と同じ言語のライブラリ、あるいは通信プロトコル形式として提供され、システム／サービス開発者によって提供・管理される。
APIを使えば、色々な製品やサービスを簡単に実装することが可能。
サービスをより多くの人に使ってもらいたいAPI提供者側が、仕様とインターフェースを提供し、サービスの利用者側はその仕様に則ってAPIを使うことで、サービスを利用することができる。
APIのプロセスは「リクエスト」と「レスポンス」で構成される。
API利用者が要求したものを、API提供者が応答する。
APIについては利用者側のメリット(開発の時間とコスト節約)ばかりに目が行っていたが、API提供側もサービスの普及やデータを集めることができるというメリットがあるらしい。
まあ、そりゃそうか。ボランティアじゃないもんね。
APIにも色々あるので、興味があるものを見つけたら「API一覧」に覚書きしていく。
Web APIとは？
Web APIは、「Web Application Programming Interface」の略。
Web上で利用できる(HTTP/HTTPS通信でやり取りする)APIのこと。
Web APIではないAPIを利用する場合は、API提供者とAPI利用者は同じ言語が使われていることが多いらしいが、Web APIの場合は、異なる言語で開発されたアプリケーション間を連携させることが可能らしいので、より汎用的に使えるっぽい。
APIと言えば、Web APIを指すこともあるようだが、一般的にはAPIというモノがあって、その中にWeb APIが包含されているというイメージ。
利用時には、利用料やメンテナンスの頻度、サポートなども実装の際には気を付けたほうがよさそう。
HTTPとは？
HTTPは、「HyperText Transfer Protocol」の略。
Webサーバーとクライアント(Webブラウザ)がデータを送受信するときに使用するプロトコル。
HTTPの構造については、このページ「TCP/IP - HTTP」がめっちゃわかりやすい。
HTTPの詳細については、このページ「MDN Web Docs：HTTPの概要」を読むことにする(まだ全然読めてないｗ)。
HTTP通信は、クライアントがサーバーにHTMLファイルを要求(リクエスト)して、サーバーが要求されたHTMLファイルなどをクライアント側に返す(レスポンス)と、WebブラウザにWebページが表示される仕組み。
ステートフルとステートレス
ステートフルは、前の状態を維持すること。ステートレスはその逆で、前の状態を維持しない(＝前後の状態に関わらず、いつも同じレスポンスを返す)。
ステートフルなプロトコル：TCP/SSH/FTPなど
ステートレスなプロトコル：UDP/HTTP/DNSなど
ルーターで言うと、RAでIPv6のアドレスを配布される場合は、払い出されるIPアドレスがいつも同じだからステートレスで、DHCPv6の場合はその時の状況で払い出されるIPアドレスが変わるからステートフル。(インフラ屋さんとしては、こっちのがわかりやすいｗ)
HTTPはステートレスだから、過去のリクエストやレスポンスが影響されることなく、同じリクエストであれば、レスポンスは必ず同じになるってことだ。
ステートレスだと、過去の状態を覚えておく必要がないので、サーバーへの負担が少ない。
つまり、負担が少ない分、サーバー側でよりたくさんのレスポンスの処理を行うことが可能である。
一方で、通信に無駄が生じるというデメリットは致し方ないといったところか。
HTTPメッセージの構成
HTTPリクエストの構成
- リクエスト行：HTTPメソッド、URI、HTTPプロトコルのバージョン
- メッセージヘッダ：Webブラウザの情報、データのタイプ、圧縮方法、言語
- 空白行：メッセージヘッダの終わりを示す
- メッセージボディ：Webサーバーに送るデータがある場合使用
HTTPレスポンスの構成
- ステータス行：HTTPバージョン、ステータスコード、ステータスメッセージ
- メッセージヘッダ：Webサーバーの情報、データのタイプ、圧縮方法
- 空白行：メッセージヘッダの終わりを示す
- メッセージボディ：HTML、画像、動画などのWebブラウザに表示させる情報
HTTPメソッド
HTTPの述語(動詞？)のようなもの。C言語で言うところの関数のようなものかな。
クライアントからサーバーに送る要求。
下記に、メソッドを列挙するが、内容については実際に使うときに追記予定。
HTTPリクエストメソッド
- GET
- HEAD
- POST
- PUT
- DELETE
- CONNECT
- OPTIONS
- TRACE
- PATCH
HTTPレスポンスステータスコード
HTTPリクエストが正常に完了したかどうかを示すコード。5つのクラスに分類されている
これも列挙はしておくものの詳細は、実際に使うときに追記予定。
こういったステータスを見て、状況に対応した画面を出していたんだな～
- 情報レスポンス(100-199)
- 成功レスポンス(200-299)
- リダイレクト(300-399)
- クライアントエラー(400-499)
- サーバーエラー(500-599)
HTTPSとは？
ここで少し、HTTPSについてもまとめておこう。(なんとなくわかってるけど、ちゃんと説明できないからｗ)
HTTPSは、「HyperText Transfer Protocol Secure」の略。
こちらも説明はWiki先生から引用。
HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信をより安全に（セキュアに）行うためのプロトコルおよびURIスキームである。厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供されるセキュアな接続の上でHTTP通信を行うことをHTTPSと呼んでいる。
えっ。HTTPSってプロトコルの名前だと思ってた。。。
確かにSSL/TSLプロトコルだわｗ
HTTPS通信の仕組み
前述の通り、HTTPS通信において、暗号化を行っているのはSSLプロトコル。
Webサーバーにサーバー証明書をインストールすることで、SSLを実現している。
※サーバー証明書には、通信を暗号化するために必要な鍵の情報や、サイトの運営者情報が記載されていて、取得するには審査が必要。
SSLは、鍵を使って通信を暗号化しているので、その鍵がないと複合化できないため、より安全にHTTP通信が利用できる、という算段である。
証明書を取得するには審査が必要だから、SSLサーバー証明書をインストールしている＝サイトの運営者がある程度信頼できることがわかる。
は～。ここでようやく本題。
ブラウザにURLを入力してサイトが表示されるまでの流れ
こんな感じかな・・・。
検索するものをデータベースに要求してごねごねして結果をもらうところとかは、まだもやっとしているので、これは学習を進めていくうちに理解できるかな。
とりあえずクライアント側とWebサーバー側のやり取りは、きっとこんな感じだと思う。
コードレベルで分かるようになると、腹落ちできるはず。(たぶん)
