迷ったときに立ち返る HTML, JavaScript, CSS 概論 (2)

前段

• 前回 HTTP とはクライアントからリクエストをサーバに投げて、レスポンスを取得することで成り立っている、とお話ししましたが、今回はその続きとして HTTP 通信の中身について少し書いておきます。
• 大雑把に説明すると、リクエストは URL とリクエストメソッドで成り立っています。

URL

• URL = Uniform Resource Locator, インターネット上に存在する情報資源(文書や画像など)の場所を指し示す識別子。

  • "プロトコル://ホスト名/パス名/ファイル名" という形式で構成される
  • プロトコル: http や https, ftp のように RFC で定義された通信方式
  • ホスト名: 資源を提供するサーバのホスト名(および、ポート番号)

• 上記のように書くと、インターネット上の情報資源の識別子は URI だ ! というおじさんに出会うかもしれませんが、RFC3986 にその辺の違いは書いてあって、 URI は URL を包含するものだと思ってください。

  • https://triple-underscore.github.io/rfc-others/RFC3986-ja.html

• たびたび出てくる RFC (Request for Comments) という言葉ですが、厳密な定義は難しいので、"インターネット上で扱う技術の標準仕様" とでも思っておいてください。メールアドレスの形式、http や　SSLのプロトコル等、インターネット上で通信を行う際の約束事が書かれています。

  • メールアドレスや URL のバリデーションを実装する際など、厳密な定義を探していくと RFC にぶつかるので、こういう文章があるということを覚えておいてください

リクエストメソッド

• HTTP ではクライアントからサーバ(URL で指定したリソース)に対してリクエストの方法のことをリクエストメソッドと言います。リクエストメソッドにはいくつか種類がありますが、代表的なものは GET と POST の2つになります。

• GET も POST も指定したリソースに対してリクエストを行い情報を取得するメソッドなのですが、それぞれ次のような特徴があります

  • GET
    • リクエスト時にサーバへ送信するデータはリクエストURLの後に付け加えられる (例: http://localhost:8080/index.html?foo1=bar1&foo2=bar2)
    • ?より後の文字をクエリストリングという
    • データ送信量に制限がある
  • POST
    • データ量が多い場合(GETでのデータ送信量制限を超えてしまう場合)に使用
    • バイナリデータを送信したい場合

• 上記のように GET の場合、サーバへのリクエストの情報が URL で確認できてしまうため、ユーザに見られたり、変更されたりしたくない情報に関しては GET を使わず、POST を使うようにしてください。

• ただ、GET の場合、リクエストが URL にて成立するので、ブックマークとして扱うことができるというメリットがあります

REST

• 最近の Web上のサービスは REST API を提供していることが多いですね

  • Web サービスと書くとおじさん達は SOAP通信を使った送受信と思ってしまうこともあるので、あえて遠回しに書いています。 Webサービスについては下記等を読んでみてもらいたいと思うのですが、実はいまだに現役で活きていたりするのであなどれない ...
    • https://ja.wikipedia.org/wiki/Web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9

• REST (= REpresentational State Transfer) とは下記の原則を持つ設計思想 (以下、wikipedia からの転記)

  • ステートレスなクライアント/サーバプロトコル
    • HTTPメッセージの一つ一つが、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含む。そのため、クライアントもサーバも、メッセージ間におけるセッションの状態を記憶しておく必要がない。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理している（URLリライティングのような一部のセッション管理手法を使うシステムは、RESTfulではない）。
  • すべての情報（リソース）に適用できる「よく定義された操作」のセット
    • HTTP では操作（メソッド）の小さなセットが定義されている。最も重要なのは "GET"、"POST"、"PUT"、"DELETE" である。これらはデータ永続化に要求されるCRUDと比較されることがある。もっとも "POST" に関してはCRUDにはぴったり対応していない。
  • リソースを一意に識別する「汎用的な構文」
    • RESTfulなシステムでは、すべてのリソースはUniform Resource Identifier (URI) で表される一意的な（ユニークな）アドレスを持つ。
  • アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
    • RESTシステムでは、多くの場合、HTML文書またはXML文書を使う。こうした文書に情報およびその他のリソースへのリンクを含める。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はない。
  • https://ja.wikipedia.org/wiki/Representational_State_Transfer

• 文字多いですね。まとめるとリソースに対する扱いを URL とリクエストメソッドだけで完結できる設計ってことですかね。なので、REST API を持つ Web上のサービスは、そのサービスの URL に対してリクエストメソッドを指定してアクセスすることでリソースを操作することができます。

  • ちなみに REST に関しても、たまに下記と混同する人がいるので注意してください。 sphinx もよくできてますよ。
    • https://ja.wikipedia.org/wiki/ReStructuredText

• セッション等の情報をもたずに URL だけでリソースへの扱いが行えるので、スケーラビリティも担保しやすいですし、システム連携用の API として REST API がはやるのも納得ですね。

  • といってもこれで本気でシステム連携しようとすると、それはそれでいろいろ問題がでるので、連携用の口を用意してますよってサービスのほうが多いような気もしてます。 実際動かそうとするとドキュメントと仕様が違うとかザラですし ...

後段

• というわけで、URL からリクエストメソッド、REST API をざっと説明してみました。 概要ということで説明が不足しているかもしれませんが、ここに出てくるキーワードの意味を知らないと後々かっこ悪いのでうろ覚えの人は覚えておいてください。

• HTML, CSS, JavaScript でこういうの知りたいとかありましたらコメントで残しておいてもらえると、次書く際の材料にしますので、よろしくお願いします。

• 次はブラウザキャッシュの扱いや開発者ツールの使い方なんかを書いてみようかななんて考えています。