Webを支える技術 第4部 まとめ

Webを支える技術

Webを支える技術　第4部のまとめ

第10章 HTML

HTMLはタグで文書の構造を表現するマークアップ言語である。HTML4.01まではSGMLがベースで開発されていた。しかし複雑だったことから、仕様をよりシンプルにしたXMLが開発され、ベースをこれに変更したものがXHTML1.0であり、モジュール化によって拡張可能にしたXHTML1.1がある。

メディアタイプ

HTMLの文字エンコーディングは、よほどのことがない限りUTF-8を使用するのが無難である。

XMLの木構造

XMLは以下のような木構造になっている。

<html>
    <head>
        <title></title>
    </head>
    <body>
        <p></p>
        <a href=""></a>
    </body>
</html>

HTMLの構成要素

HTMLの基本的な構成要素はヘッダとボディであり、ヘッダ文書のメタデータとボディには文書の内容そのものを入れる。

リンク要素

  • aタグ - アンカー body内に埋め込む、別のWebページに移動するためのタグ

  • linkタグ Webページ同士の関係を指定するタグ。 body内に埋め込むaタグに対し、こちらはhead内に埋め込む。

  • form HTTPのGETやPOSTを利用して、結果を特定のURIに送信する機能。

リンク関係

Web APIのようにクライアントが人間ではなくプログラムである場合は、それぞれのリンクがどのような意味かを解釈し、どのリンクを辿るべきか機械的に判断する仕組みが必要になる。 そのためHTMLやAtomは、リンクの意味をプログラムが可読な状態で記述するための機構を用意している。

  • rel属性 「a」と「link」要素は、「rel」属性を持てる。relには、リンク元のリソースとリンク先のリソースがどのような関係にあるかを記述する。

「index.html」が「example.jp」にある「base.css」を参照する場合

<link rel = "stylesheet" href = "http://example.jp/base.css"/>

第11章 microformats

HTMLは見出しや段落などの構造を定義した文書フォーマットだったが、その中で更に意味のあるデータを表現するための技術がmicroformatsである。 microformatsは「より簡単に、もっと気軽にWebページのセマンティクスを記述できるようにしよう」という目的の元、開発された。

※セマンティック(Web)

  • 要約するとWebページ内の細かな情報に意味を持たせ、検索エンジンなどの検索に引っかかりやすくすること
    • 住所、緯度や経度
    • 楽曲情報など

デメリット

  • 同じclass属性やrel属性を持つWebページが存在していた場合、プログラムがご判定を起こしたり同じ属性を持ったmicroformatsが作成できなくなる

  • 上記の問題を解決するためにW3Cが標準化を進めている「RDFa」がある。これはXMLの名前空間を使用して衝突問題を回避できるが、複雑な点やXHTMLでしか使用できないというデメリットもある。

リソースの表現としてのmicroformats

従来のHTML表現は人が閲覧するために利用されているため、プログラムでの処理に利用するのは難しかった。 そのため、プログラム用のJSONなどのデータフォーマットを用意していたが、プログラム用に別のAPIを提供することは以下のような弱点を抱えている.

  • WebサービスとAPIで機能が異なってしないがち
  • 開発規模の増大に伴うメンテナンス性の低下
  • Web APIに必要な技術の開発コストがかかる

microformatsはWebページをそのままWebAPIとして提供できるため、以下のようなメリットが期待できる。

  • ページとAPIでの機能差を無くす
  • 開発はWebページだけで済むため、開発コストを抑えることやメンテナンス性の向上
  • 新たにAPIを作る必要性がないため、学習コストも大幅に抑えられる

第12章 Atom

Atomとは、RFC4287が規定するXMLフォーマットであり、乱立していたRSSの仕様に対し、拡張性のあるフィードの標準フォーマットを策定しようという目的があった。

メンバリソース

Atomにおける最小のリソース単位はメンバリソースである。 例を上げるならば、ブログサービスにおける一つ一つの記事、画像保存サービスにおける一つ一つの画像。

尚メンバリソースは、XMLのみで表現できるエントリリソース(文字)と、それ以外のメディアリソース(画像、音楽など)に分類され、それぞれ「entry」「feed」と明示される。

コレクションリソース

コレクションリソースは複数のメンバリソースを含むリソースであり、階層化はできない。そのため、コレクションリソースが他のコレクションリソースを含むことはできない。

イメージ

  • コレクションリソース
    • メンバ
    • メンバ
  • コレクションリソース
    • メンバ

↓これはできない

  • コレクションリソース
    • コレクションリソース

メディアタイプ

Atomのメディアタイプは「application/atom+xml」である。

  • typeパラメータなし Content-Type: application/atom+xml

  • エントリ Content-Type: application/atom+xml; type=entry

  • フィード Content-Type: application/atom+xml; type=feed

  • typeとcharsetパラメータを指定 Content-Type: application/atom+xml; type=feed; charset=utf-8

名前空間

http://www.w3.org/2005/Atom

拡張子

「.atom」

エントリ

前述の通り、エントリはエントリリソースの最

メタデータ

ID

エントリを一意に示すURI形式のID。tagスキームのURIがよく用いられている。

tag:{NS名もしくはメールアドレス},{日付}:{任意の文字列}

DNSもしくはメールアドレスに日付情報を加えることで、グローバルに一意であることを保証する。

タイトルと概要

  • 「title」要素(必須) エントリの題名を表現する

  • 「summary」要素 エントリの概要を表現する

また、type属性として「text」「html」「xhtml」といった値を持ち、この値によって内容が変化する。

著者と貢献者

  • 「auther」要素(必須) 著者を表現する

  • 「contributer」要素 貢献者を表現する

なお、「auther」「contributer」は以下の要素が必須である。

  • 「name」要素(必須) 自然言語で記述した名前

  • 「uri」要素 人に関連付けられたURI

  • 「email」要素 人のメールアドレス

公開日時と更新日時

  • 「updated」(必須) 更新日時

  • 「published」 公開日時

カテゴリ

カテゴリは、Webサービスなどにおけるタグ(タグ付けと言われるような)のようなもので、「category」で表現する。

リンク

「link」で表現する

フィード

必須要素はエントリと同じ

フィード独自のメタデータ

サブタイトル

「subtitle」 タイトルで説明しきれない説明を記述

生成プログラム

「generator」 フィードで生成したプログラムの情報を表現

アイコン

「icon」 faviconの指定

ロゴ

「logo」 当該フィードを象徴する画像の指定

Atomを活用する

Atomは「タイトル」「著者」「更新日時」などといった基本的なメタデータを備えたリソース表現のためのフォーマットである。 特に上記3点のデータはブログ以外のコンテンツでも有用なことが多い。

第13章 Atom Publishing Protocol (Atom Pub)

AtomとAtomPubの関係

  • Atom データフォーマットの規定

  • AtomPub Atomを利用したリソース編集プロトコルの規定

AtomPubの存在意義

ブログを編集するためのプロトコルはいくつも存在していたが、ブログ機能に特化していたため、国際化や拡張性で問題点があった。

AtomPubはこれを改善するため、汎用的なWeb APIの基礎を成すプロトコルを備えている。

第14章 JSON

JavaScriptの記法で記述されたデータの形式

拡張子

「.json」を推奨

JSONが持てるデータ

  • オブジェクト型
  • 配列
  • 文字列
  • 数値
  • bool(論理型)
  • null

※参考

・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH