はじめに

タイトルの通り、知識ゼロの状態からプログラミング学習を始めて1年が経とうとしています。今まではプログラミングスクールに通い、なんとか個人開発アプリを作成することが出来ましたが、正直Web技術（HTTP,HTML,URI等）周りの知識はかなり曖昧なままなんとなくで進めて来てしまっていたので、今回このタイミングで軽く整理してみました。

学習として使用させていただいた書籍は「Webを支える技術」「Web技術の基本」です。今回はこちらを参考にさせていただいています。

また、細かい知識の解説は他の記事や動画に任せてしまいました🙇

そもそもWeb技術って？

インターネット上でウェブページやウェブアプリケーションを作成、表示、動作させるために使用される技術。
例えば…

HTTP
HTML
URI

などなど。１度アプリ開発をやってみているので、もちろん聞いたことがあります。
ただ、

「HTTPは通信プロトコル？みたいなやつでサーバー同士がやりとりするもの…」
「HTMLはページの構造を書くやつ…」
「URIは、URLのことじゃないの…？」

のように、説明してと言われたらできないのが本音です。それでここまで来たのはやばいかもしれませんが…🙇

書籍「Webを支える技術」によると、Webを支える最も基本的な技術は、先ほど挙げた「HTTP」「URI」「HTML」とのことなので、今回はこのうち「HTTP」「URI」の2つを中心に整理していきます。

といいつつ、まずは「REST」について

なぜ急にRESTという言葉がでてきたかというと、RESTはWebのアーキテクチャスタイルだからです。

…？？？

自分でも書いてて意味がわかりません。

アーキテクチャスタイルとは

ソフトウェアシステムの設計における一連の原則、パターン、または制約のこと。
まだイメージしづらいので、建築における建築構造に例えてみる。

例えば、パッと思い浮かぶ構造は「木造」「軽量鉄骨」「鉄筋コンクリート」です。
これらの構造パターンは、だいたいどのように設計するのか、なんの材料を使うのかなどのガイドラインがそれぞれあるはずです。（おそらく）
このそれぞれの構造パターンが、いわゆるアーキテクチャスタイルだと自分は認識しました。

ではソフトウェアシステムに話を戻すと、これらも「クライアント/サーバー」「MVC」などの様々な異なるアーキテクチャスタイルがあります。
Railsを学習中によく聞いていた「MVC」の場合、「Model-View-Controllerという設計になる」と言いますが、これもアーキテクチャスタイルだったんですね。
（つまり、「ModelとViewとConrollerを分けて作って、コードの整理と管理を容易にしましょうね」というガイドラインがあるということか）

RESTとは

はい、少し遠回りしましたが、つまりRESTもアーキテクチャスタイルの一つであり、かつWebにはRESTが使われている、ということですね。
では、RESTはどういったアーキテクチャスタイルなのだろう。

RESTは数あるアーキテクチャスタイルの中でも特にネットワークシステムのアーキテクチャスタイルになります。

参考「ネットワークとは？初心者にもわかりやすく解説」
https://www.ntt.com/business/services/network/internet-connect/ocn-business/bocn/knowledge/archive_100.html

といいつつ、ネットワークシステムのアーキテクチャスタイルとして最も有名なのはクライアント/サーバみたいです。サーバとクライアントが線で結び付いているあの絵ですね。

そして、Webはクライアント/サーバでもあります。

…？？？

え、WebのアーキテクチャスタイルはRESTなのではないの？？

と思ってしまいましたが、どうやらRESTはクライアント/サーバから派生したアーキテクチャスタイルみたいです。素のクライアント/サーバアーキテクチャスタイルにいくつかの制約を加えていくと、 RESTアーキテクチャスタイルになるそうです。なるほど。

ではどんな制約をクライアント/サーバーに追加して、RESTというアーキテクチャスタイルになったのか。

統一インターフェース
⇨あらかじめ定義・共有された方法で情報がやりとりされる。WebであればHTTP（後述）メソッドを使ってやりとりしてね！ということ。
ステートレス性
⇨やりとりは1回ごとに完結して、前のやりとりの結果に影響を受けない。※参考記事
アドレス可能性
⇨全てのWeb上の情報（リソース）が一意なURLの構文で示される。
接続性
⇨やりとりされる情報にはリンクを含めることができる。

※他にもいくつか制約があるみたいですが、今回は書籍「Web技術の基本」を参考にして記述しました。

そして、これらの原則に従って設計されたシステムを、RESTfulなシステムと呼ばれるのだそう。

これを頭に入れておいて、ようやく次に進みます。

「URI」についての整理

URIは「Uniform Resource Identifier」の略で、直訳すると「統一リソース識別子」です。つまりURIとは「リソースを統一的に識別するID」のことです。

リソースとは、Web上にある情報のこと。要は、URIを使うとWeb上に存在する全てのリソースを一意に示せて、全てのリソースに簡単にアクセスできるということらしい。そしてこれを実現できるのは、URIの構文に秘密があるとのことなので、もう少し詳しくみていく。

一般的・簡単なURIの例

http://blog.example.jp/entries/1
このURIを構成するパーツは次のようになる。

URIスキーム： http
ホスト名： blog.example.jp
パス： /entries/1

URIスキームは、そのURIが利用するプロトコルを示すのが一般的です。上記の場合はHTTP（後述）を利用してアクセスしてねということ。
次にホスト名が出てきますが、ホスト名はDNSで名前が解決できるIPアドレスであり、インターネット上で必ず一意になる。

参考「DNSとは」
https://www.gmo.jp/security/brandsecurity/dns/

最後に階層を表すパスがきます。これはホストの中でリソースを一意に指し示すものです。

このような仕組みにより、あるリソースのURIが世界中の他のリソースのURIと重複しないようになっているみたいです。

URIとURLの違いは？

先ほどから当たり前のようにURIと使っていましたが、よく聞くのはURLだよな〜ということで違いについては以下の記事の通りです。

「HTTP」についての整理

HTTPとは

まずは概要から

WebサーバーとWebブラウザの間でWeb情報をやりとりするためのプロトコル（通信規則）です。プロトコルとは、コンピュータとコンピュータがネットワークを通じて通信する際に決められた約束事・決まりのことを言います。

参考

Webサーバーとは、Webブラウザからコンテンツの要求があると、必要なコンテンツをネットワークを通してWebブラウザに送信する役割をもつもの。

TCP/IPとは

いきなり出てきましたが、HTTPはTCP/IPをベースにしているとのことなので、聞いたことがあるこれについてもここで整理します。

TCP/IPとは、インターネットを含む多くのコンピュータネットワークにおいて、世界標準的に利用されている通信プロトコルのことです。TCP/IPはインターネット・プロトコル・スイートとも呼ばれ、World Wide Webの発明と共にコンピュータ及びコンピュータネットワークに革命をもたらしたことがきっかけで現在でも標準的に利用されている通信規則です。インターネットを利用する際は異なるハードウェアやOSであっても通信が確立していなければネットワークは繋がりません。従ってTCP/IPは機器やOSが異なっても共通のプロトコルを用いて通信を成立させるものです。

参考記事

つまり、TCP/IPも通信プロトコルなんですね。
でも、ここで訳わからないのが、「さっきHTTPもプロトコルって言ってたじゃん、どっちを使うんだよ、、」と自分はなってしまいました。
ここで先ほど言及した「HTTPはTCP/IPをベースにしている」が出てきます。

TCP/IPの通信は、大きく4つの階層に分かれている。

上位のレイヤーから、

アプリケーション層
トランスポート層
インターネット層
ネットワークインターフェイス層

となっていて、それぞれ以下のような役割を持っています。

1. ネットワークインターフェース層

物理的なケーブルやネットワークアダプタに相当する部分。
例：イーサネット

2. インターネット層

ネットワークでデータを実際にやりとりする部分。
例：IP

3. トランスポート層

データの転送を保証する役割
例：TCP, UDP

４. アプリケーション層

具体的なインターネットアプリケーション、例えばメールやDNS、そしてHTTPを実現する役割
例：HTTP, SMTP

やっと出てきた！HTTP！！
つまり、「HTTPはTCP/IPをベースにしている」ていうのは、大きいプロトコルの括りがTCP/IPで、その中にHTTPというプロトコルがあるということですね。

全体的な流れは以下の記事、動画も参考にしました。

ちなみに、少しずれますが、「なんでTCPとIPだけ優遇されて名前として呼ばれてるんだ？」と思いましたが、それは以下の記事を読みました。

HTTPの具体的な仕組み

では、アプリケーション層で行われるHTTP通信を行う際、具体的にどのような仕組みで動くのでしょうか。
⇨HTTPでは、クライアントが出した「リクエスト」をサーバで処理して「レスポンス」を返す。

大まかな流れとしては、

クライアントでリクエストメッセージの構築・送信
サーバでリクエストメッセージの受信・解析
メッセージの内容を元に、アプリケーションプログラム（Railsとか）へ処理をお願い
サーバがアプリケーションプログラムからその結果を取得
その内容を元にサーバがレスポンスメッセージの構築・送信
クライアントがレスポンスメッセージの受信・解析
クライアントの目的を達成するための処理（例えばHTMLをレンダリングするなど）

クライアントが構築するリクエストメッセージやサーバーが構築するレスポンスメッセージを総じて「HTTPメッセージ」と呼びます。
リクエストメッセージにはHTTPメソッド（後述）や、リクエスト先のURIなどが含まれます。
レスポンスメッセージにはステータスコード（後述）やHTMLが含まれたボディなどが含まれます。

HTTPメソッド

先ほどちらっと出てきたHTTPメソッドについて整理します。
HTTPメソッドには、クライアントが行いたい処理をサーバーに伝えるという重要な任務があります。よく聞くのがGETとかPOST、PUTやDELETEですよね。
それぞれのメソッドが何をしたいのかはなんとなくわかっていましたが、今一度以下のサイトで整理しました。

ここでRailsでの個人開発を思い出すと、Railsのビューで用意されたリンクやフォームは、背後で特定のHTTPメソッドを使用するように設定されているんだなと思いました。link_toはGET（オプションによってはDELETE）だったり、form_withだとPOSTやPUTだったりと。
Railsアプリケーションでは、クライアントが送信するHTTPメソッドは、実際にはRailsのビューヘルパーによって大きく影響を受けていることがわかります。

ステータスコード

全てのリクエストにはレスポンスが返ります。
よくみる200や404といった数字がありますが、それぞれ意味があります。これもなんとなく理解していましたが、覚えていないのでこれは以下の記事で整理しました。

ところで、HTTPSとは？

httpsとは「Hypertext Transfer Protocol Secure」の略称で、SSL/TLSプロトコルにより暗号化されたhttp通信の事です。（基本的な通信方法はHTTPと変わらない）

「http」から始まっている場合は、通常のhttp通信であり、データの送信は平文で行われています。
一方で、「https」から始まっている場合は、SSL/TLSプロトコルを利用した、暗号化通信が行われています。

SSL/TLSプロトコルって？

まずSSLとは、Secure Sockets Layerの略で、インターネット上のウェブブラウザとウェブサーバ間でのデータの通信を暗号化し、送受信させる仕組みこと。
一方でTLSとは、Transport Layer Securityの略で、超ざっくりいうとSSLの進化バージョンだそうです。

1994年に、SSL2.0がウェブブラウザ「Netscape Navigator 1.1」に実装され、SSLが広く一般に知れ渡るようになりました。その後、1999年にSSL3.0を基にしたTLSが登場しましたが、既にSSLという名称が広く使われていたために、現在では「TLSのことも含めてSSLと呼ぶ」または「SSL/TLS」「TLS/SSL」のような併記で使われる事が多いです。

具体的な暗号化通信の仕組みは、以下のサイトを参考にしました。

最後に

色々整理したり、自分が参考にした記事載っけたりしましたが、改めて読むと、人に読んでもらうものというよりは自分の学習まとめみたいになってしまいました🙇

ただ、このタイミングでWeb技術について整理できたのはよかったです。正直、書籍「Webを支える技術」は、以前読んだ時はかなり難しく感じてあまり頭に入ってこず、途中でやめてしまったのですが、今回は少し理解できる部分もありました。ただまだわからない点もあったので、またしばらくしたら整理する時間を取ろうと思います。