積極的後進

後ろ向きに全力ダッシュ

Webを支える技術を読んだ

会社の本棚にあったものを読むことにした。

普段の生活や業務の中で息をするようにHTTPに触れているが、HTTPのことちゃんと理解してないのでは?と思い読み始めた。

RESTやHTTPの成り立ちや基本的なところのおさらい、特にヘッダーまわりについてはちゃんと意識することが無かったので新しい発見があった。一方で、流石に内容の陳腐化も進んでしまっていた。ATOMまわりはぼんやりしか知らなかったのでそれはそれで面白かったが。

以下読書メモ。

REST Webのアーキテクチャスタイル

  • アーキテクチャアーキテクチャスタイルは異なる
  • RESTはネットワークシステムのアーキテクチャスタイル
    • クライアント/サーバーに特に有効
      • まさにWeb
  • リソースの名前 = URI
    • リソース = Web上の情報
  • RESTは、複数のアーキテクチャスタイルを組み合わせて成り立っている
    • クライアント/サーバー
    • ステートレスサーバー
      • クッキーでのセッション管理はこれに反する
    • キャッシュ
    • 統一インターフェース
      • ここでのインターフェースは、GETやPOSTを指している @
    • 階層化システム
    • コードオンデマンド: プログラムをクライアントにダウンロードして実行する

URI

  • URIの構成
    • スキーム: http
    • ホスト名: hogefuga.com
    • パス
  • ベースURI
    • 相対URI時に、ホスト名までを指定しておく
    • リソースのURIをベースとするか、要素で指定することが出来る
  • %エンコーディングには、混乱を避けるためなるべくUTF-8を用いることが望ましい
  • URIとURLの違い
    • URI ≒ URLと思ってよさそう
    • URLには、ドメイン更新やサーバー変更等でアクセスできなくなる可能性がある
    • URIはリソースの所在を表す表記ルールの総称
      • 技術仕様等ではURI表記になることがある
    • URLはリソースの所在を表す

HTTP

  • TCP/IPとは
    • インターネットのプロトコルは階層型プロトコル
    • ネットワークインターフェース層
      • ケーブルとか
    • インターネット層
      • ネットワークで実際にデータをやり取りする部分
      • IPとは、インターネット層のプロトコルのこと
      • IPでは、送り出したデータが相手に届くかまでは保証しない
    • トランスポート層
      • IPが保証しなかったデータの転送、到達を保証する
      • TCPが接続先にコネクションを張り、データの抜け漏れをチェック
      • ポート番号は、TCPで接続したコネクションがどのアプリケーションに使われるかを決定する
    • アプリケーション層
      • メールやDNSHTTPSを実現する層
      • ソケットとは、TCPでプログラムを用いるときに使うライブラリ
    • リクエスト/レスポンス
      • クライアント
        • リクエスト・メッセージの構築、送信
        • レスポンスメッセージの受信、解析
        • その他、クライアントの目的に必要な処理
      • サーバー
        • リクエストの受信、解析
        • 適切なアプリケーションプログラムへの処理の委譲
        • アプリケーションプログラムから処理結果を受け取る
        • レスポンスメッセージの構築、送信
      • メッセージの構成要素
      • HTTPのステートレス性
        • ステートフルな通信(サーバーがクライアントのアプリケーション状態を管理する)のは、台数が増えるほど難しい
          • ステートレス一択
        • ステートレスのデメリット
          • パフィーマンスの低下
            • クライアントは必要な情報を毎回取得する必要がある
            • データ量の増加、認証などの負荷。。。
          • 通信エラーへの対応
            • 意図せずリクエストが繰り返されてしまった場合など

HTTPメソッド

  • POSTでPUT/DELETEを代用する
    • _methodパラメータ
      • formの中にtype=hiddenなinput要素を配置し、idを_methodとする
      • valueに書いたメソッドが使える
      • application/x-www-form-urlencodedの場合にのみ使える
    • X-HTTP-Method-Override
  • 条件付きリクエス
    • HTTPメソッドと更新日時などのヘッダを組み合わせて、メソッドの実行可否をキメられる
    • If-Modified-Sinceヘッダなど
  • 冪等性と安全性
    • 冪等性: ある操作を何回行っても結果が同じこと
    • 安全: 捜査対象のリソースの状態を変化させないこと
      • 変化を与える: 副作用

ステータスコード

  • 仕様で定められたステータスコードを正しく使いたい
  • 分類
    • 1xx: 処理中
    • 2xx: 成功
    • 3xx: リダイレクト
    • 4xx: クライアントエラー
    • 5xx: サーバーエラー

HTTPヘッダ

  • メタデータ
  • 認証やキャッシュなどHTTPの機能はヘッダで実現する
  • ヘッダの機能
    • 日時
      • Date
      • Expires
    • MIMEメディアタイプ
    • 言語タグ
      • Content-Langugage: ja-JP
    • コンテントネゴシエーション
      • Accept
        • クライアントが処理できるメディアタイプをサーバーに伝える
      • Accept-Charset
      • Accept-Language
    • Contente-Length
    • 認証
      • Authorization
    • キャッシュ
      • Pragma
        • キャッシュ禁止
      • Expires
      • Cache-Control
        • 詳細なキャッシュ方法の指定
        • 前述の指定はここでもできる
        • max-ageとか
      • 条件付きGET
        • If-Modified-Since

microformats

  • classやrel属性でメタデータを表す
    • さらに、rel="home" などの rel 属性を活用したメタデータの定義も推奨されていますが、これは HTML5 においては誤った構文となります。 rel 属性は、それを使える要素とその値が定められています。
  • wordpressでは採用されてる
  • microformats は競合する他のメタデータのフォーマットと比較して、古くから存在し、Wordpress などでも採用されていることから、 検索エンジンも採用したのだと考えられます。(他に Yahoo が一部取り入れているようです。)ただし、Googleschema.org の提唱するメタデータを採用するように推奨しています。 schema.org は、Google, Yahoo, Bing(Microsoft) などが共同で管理する団体です。 また schema.org が提唱するメタデータの記述形式、microdata や RDFa フォーマットは、W3C で制定されるフォーマットです。検索エンジンを提供する各社が microformats のサポートを直ぐに止めることは考えられませんが、 今後は schema.orgメタデータmicrodata フォーマットでマークアップ(記述)することがスタンダードになっていくと思われます。
  • SEOに寄与するかも微妙、標準化競争に負けたように見える

Atom