Help us understand the problem. What is going on with this article?

webを支える技術を自分の言葉で要約する

はじめに

初心者がWEBを支える技術を読むにあたり、単語の意味とそれが何を示してるのかわからないので
読んで進めていても理解しにくい。自分なりに理解し、アウトプットする事で、理解を深めていく。

書籍URL
https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%E3%80%81URI%E3%80%81HTML%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus/dp/4774142042/ref=sr_1_1?adgrpid=52846719243&hvadid=338588425160&hvdev=c&hvlocphy=1009298&hvnetw=g&hvpos=1t1&hvqmt=e&hvrand=6495890101632290940&hvtargid=kwd-333749887651&jp-ad-ap=0&keywords=web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93&qid=1555557065&s=gateway&sr=8-1

WEBとは何か?

大きく3種類に分類される。

WEBサイト

一番イメージしやすい。グーグルのページとか。
どうやって表示しているのか、どうやって処理しているのかをイメージしなくても
ユーザーが使えるのがWEBの魅力である。

ユーザインタフェースとしてのWeb

見た目を整えて、ブラウザの設定をしたりする。
昔はハードのリモコンボタンでしていたが、今はブラウザ上で設定するのがほとんど。

端的に言えば、フロントエンドエンジニアが関わる領域。

プログラム用APIとしてのWeb

本書では、ややこしいのでWebAPIと呼ぶ。
端的に言えば、バックエンドエンジニアが関わる領域。
APIはプログラム用のインタフェース。ってイメージ。
データフォーマットにはXML(ExtensibleMarkupLanguage)
JSON(JavaScriptObjectNotation)を使う。

XMLについて詳細  https://www.graffe.jp/blog/2911/
JSONについて詳細 https://www.json.org/json-ja.html

WEBを支える根幹の技術

HTTP(URLとHTMLをやり取りする為する取り決め)
URL(WEB住所)
HTML(WEB文字)

HTMLはXMLを基にした汎用の言語。

ハイパーメディアと分散型システム

WEBを支える技術の根幹にある。

ハイパーメディア

リンクでデーターを結びつける事。
書籍などで目次を確認する以外だと"ドラえもんの生態"のページを探すには先頭から読むしかなかったが
リンクを結びつける事で"ドラえもん"と検索するだけで対象ページが見つかるようになった。

分散システム

一箇所にあるコンピューターで処理するのでなく、世界中に散りばめられたサーバーにアクセルする事で多数のコンピューターで処理ができる。
様々なパソコンが同時にアクセスし処理ができるのは、HTTPのプロトコルが簡単だから。

WEBの歴史

インターネットの始まりなどは割愛。

RPCは分散システムを実現する為に必要な技術(昔は)
ただ、問題があり、大規模分散システムとはならない。

1990年にバーナーズリーガWEBを発明。サーバーとブラウザを公開。
最初流行ったブラウザはモザイク。
RPCと違い、HTTPのプロトコルが簡単だから流行った。誰でもアクセルできるって感じかな。

ロイフィールディングがWEBのアーキテクチャを決定付けた(構造)
このアーキテクチャをRESTと名付けた

ハイパーメディアの複雑化

情報のやり取りがHTMLだけだと対応できなくなって新たな仕組みが生まれた。
microformats
RSS
JSON

今後学習する上で必要なら上記言葉の意味を理解するにとどめる。

文書を読むためのWEBからプログラムを実行するためのWEBへ

アマゾンが2002年に自社で扱う書籍のデーターをWEBを通じてプログラムで取得する技術を開発した。
これにより、WEBを使って処理するのが素晴らしいと世の中が便利さに気づき始める。
RPCの技術を発展させたプロトコルも出てはいたが、複雑さと政治的な理由から現在のWEBの技術にインターネットが飲み込まれ始める。

RESTというアーキテクチャスタイル(第3章始まり)

スクリーンショット 2019-04-22 15.12.11.png

アーキテクチャスタイルとはRESTその物の事をさす。

実装を一つ抽象度をあげたものをアーキテクチャと呼び更に抽象度をあげたものをアーキテクチャスタイル(REST)と呼ぶ。
RESTを構成する重要な概念を順に紹介する。

リソースとは

RESTの重要な概念の一つ。WEB上に存在するありとあらゆる名前を持った情報の事。
リソースの名前とはURLの事です。
このURLがもつリソースの情報を簡単に指し示す事のできる性質を<アドレス可能性>よーするにURLにちゃんとした名前をつけておけば、プログラムを作成しやすくなります。一つの情報は複数のURLを持つ事ができる。サーバーとクライアントの間でやり取りするデーターを<リソースの表現>と呼ぶ。

サーバーとクライアント(アーキテクチャスタイルその1)

HTTPプロトコル。プロトコルとは手順や約束事。HTTPプロトコルに準じて、サーバとクライアントがやり取りをする。
スクリーンショット 2019-04-22 15.24.41.png

この仕組みのメリットはクライアントとサーバを分離し処理ができる。だからクライアントをマルチプラットフォームにできる。よーするにWEBは携帯からPCゲームまでなんでもやり取りができる。しかもUIはクライアント側の仕事のため、サーバーはデーターストレージとしての機能をもつだけで良い。 (ストレージ 記憶装置)

ステートレスサーバー(アーキテクチャスタイルその2)

クライアントのアプリケーションの状態をサーバーで管理しない事。これによりサーバーの実装を簡素化できる。ただ現実にはCookieを使ったセッション管理などあえてステートレスではない処理をしているケースもある。あくまでの必要最低限の実装にする理解で留めておく。
スクリーンショット 2019-04-22 15.33.40.png

キャッシュ(アーキテクチャスタイルその3)

一度取得したリソースをクライアント側で使い回す事。
メリットはサーバーの通信を減らすことで負担減となる。

統一のインターフェイス(アーキテクチャスタイルその4)

限定した8個のメソッドで処理をする。これ以上メソッドを拡張出来ない制限を加えることで、シンプルなアーキテクチャを実現した。この統一インターフェイスがRESTを印象づけるアーキテクチャです。
スクリーンショット 2019-04-22 15.39.25.png

階層化システム(アーキテクチャスタイルその5)

統一UIを採用していることで階層化システムを採用しやすくなっている。
サーバーの負荷分散のためにプロキシを設置してアクセスを制限したりする。
スクリーンショット 2019-04-22 16.09.59.png

プロキシとは

直訳は代理。統一したUIのおかげで、クライアントはプロキシに繋がろうが、サーバーに繋がろうが、意識することはない。
サーバーに対しては、クライアントの情報を受け取る。クライアントに対してはサーバーの情報をサーバーの働きをする。

コードオンデマンド(アーキテクチャスタイルその6)

サーバーからプログラムコードをDLしてクライアントで実行するアーキテクチャスタイル。
メリットはクライアントを後からいくらでも拡張できる事。HTTPアプリケーションプロトコルに従って通信している間はリソースは明白なのに対して、DLしクライアントで実行してしまうので、可視性は低下する。

スクリーンショット 2019-04-22 15.51.39.png

RESTのアーキテクチャスタイルのまとめ

この6つを組み合わせたアーキテクチャスタイルをRESTと呼ぶ。

1クライアント/サーバーをで分けて、ユーザーインターフェイスと処理を分離する事
2ステートレスサーバー(サーバー側でアプリケーションの状態を持たない)
3キャッシュ(サーバーとクライアントの通信を減らす)
4統一インターフェイス
5階層化システム
6コードオンデマンド

アプリケーション状態エンジンとしてのハイパーメディア

WEB上のリソースが持つリンクを辿ってその作業をいくつか実施することで一つのアプリケーションを実現すること
この考え方は接続性とも呼ばれる。

RESTful

RESTの制約に従って、RESTらしい設計をする事

URLの設計と実装について(第4章始まり)

URLは日本語で言い換えると、リソースを統一的に認識するID。つまりURLさえあれば、WEB上にあるリソースを全て指し示す事が出来る。

URLを構成するパーツの例(簡単な構成バージョン)

http://blog.example.jp/entries/1

まずリソースにhttpでアクセスすると宣言。://をつけるのがルール。
ホスト名は必ず被らない名前かIPアドレスを使う。そのホストの中でリソースが被らないように階層パスが続く。

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

URLを構成するパーツの例(複雑バージョン)

http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10

ユーザー名とパスワードは<:>で区切ります。
HTTPのポート番号のデェフォルト値は80番です。
クエリパラメーターはクライアントから動的にURLを生成します。(いまいちわからん)
URIフラグメントはクエリパラメメーターで指定したURLのさらに細かいリソースを指定するときに使用する。
例えば、それがHTML文だった場合はod属性値がn10である要素となる。

・URIスキーム:http
・ユーザ情報:yohei:pass
・ホスト名:blog.example.jp
・ポート番号:8000・パス:/search
・クエリパラメータ:q=test&debug=true
・URIフラグメント:#n10

相対URIと絶対URI

絶対URIは階層全て記載するイメージ。

http://example.jp/foo/bar

相対URI

URIスキームやホスト名を除く。

/foo/bar

見てわかるように、相対URIだけではクライアントが場所を認識できない。
相対URIでもURIを認識するようにしなければならない。
その為に絶対から相対にURIを変える事を相対URIを解決するという。

相対URIを解決する手段

HTMLの場合、

に情報を加え、明示的にする。

%エンコーティング

URIで対応していない文字列を変換し表示すること。
スクリーンショット 2019-04-25 21.01.24.png

URI長さ制限

IEが2038バイトまでしか対応していないので、それ以下の容量とする。

URI実装で気をつける事

相対URIを解決する事。
%エンコーティングの扱いでUTF-8を使用する事。

URIとURLの違い簡単に説明

URIはURLとURNの総称。

URLはドメインを更新しない時やサーバーが何かしらの障害で変更になったときにアクセス出来なくなる仕組み。

その保険的なイメージでURNとはドメイン名とは独立してリソースに恒久的にID(名前)をつける事。
但し、URNは取得ができない。WEBの価値が向上し、URLで十分永続的に接続出来るようになっている。

インターネットのプロトコルは階層型 第6章

4つの層に分かれている。

階層型プロトコ.png

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

物理的なケーブルやアダプタに相当する部分。

インターネット層

この層を担当するのが、IPです。IPではデーターの通信単位をパケットと呼ぶ。
パケットとは指定したIPアドレスをパケット単位で通信している。
送り出したデーターが最終的な送り先まで届くかは保証しない。

トランスポート層

IPが保証しなかったデーターの転送を保証する。TCPが相当する。
保証の仕方は、コネクションを使って漏れをチェックする。どのアプリケーションに渡るのかを決定するのがポート番号。

アプリケーション層

HTTPやメールやDNSを実現する層です。 

HTTPのバージョンについて

今は1、1で後継のバージョンも議論されている。
ただ、現在ではRESTアーキテクチャスタイルに価値を見出しており、HTTP1.1を有効に活用できる開発をしていく流れとなっている。

リクエストとレスポンスについて

HTTPはクライアントが出したリクエストをサーバーで処理してレスポンスを返します。
クライアントはレスポンスが返るまで待機します。

クライアントで行われる事

1.リクエストメッセージの構築
2.リクエストのメッセージの送信
3.(レスポンスが返るまで待機)
4.レスポンスメッセージの受信
5.レスポンスメッセージの解析
6.クライアントの目的を達成するために必要な処理

サーバーで行われる事

1.(リクエストの待機)
2.リクエストのメッセージの受信
3.リクエストメッセージの解析
4.適切なアプリケーションプログラムへの処理の委譲
5.アプリケーションプログラムから結果を取得
6.レスポンスメッセージの構築
7.レスポンスメッセージの送信

HTTPメッセージ

リクエストメッセージとレスポンスメッセージをまとめた言い方。
HTTPのメッセージの構造
スクリーンショット 2019-04-27 21.55.23.png

ステートフルとステートレスについて

RESTの設計の重要なアーキテクチャである。
ステートレスなサーバー設計ですが、意味を完結に表すなら、ステートレスはくどい会話になる。
一見ステートフルがいいように見えるが、無数のクライアントのリクエストを受けるサーバーにおいて、処理しきれない問題が生じる。

ステートレスの欠点

送信するデーター量が多くなる。
リクエストを重複してレスポンスを返す恐れがある。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away