「Webを支える技術」まとめ(第1部〜第3部)の続きになります。
第十章 HTML(Hyper Text Markup Language)
HTMLのメディアタイプ
- text/html:SGMLベース
SGMLはマークアップ言語の1つで過去のHTMLはこの言語をベースに作られていた。 - application/xhtml+xml:XMLベース
文字エンコーディングはUTF-8を使うのが無難と言える。
XMLの基礎知識
XML文書は木構造として表現できる。
- html
- head
- title
- body
- h1
- p
- head
XMLの木構造はそれぞれの要素(headやp)を入れ子にして表現する。このとき
- htmlはheadやbodyの親要素
- headやbodyはhtmlの子要素
属性
要素は属性を持つことができ、開始タグの中に属性名="属性値"という形式で記述される。属性は以下の特徴を持つ。
- 属性は複数持つことができる。
- 属性は入れ子にできず、開始タグの中の属性の順番には意味がない。
XML宣言
XML文書の先頭にXML宣言を書く。XML宣言ではXMLのバージョンと文字エンコーディング方式を指定する。
バージョンは基本的に1.0を、文字エンコーディングはUTF-8の使用が推奨される。なお、この場合XML宣言では省略してもよい。
HTMLの構成要素
- ヘッダ
- title, link, script, metaなど
- ボディ
- ブロックレベル要素
- h1, div, p, table, formなど
- インライン要素
- em, code, var, aなど
- ブロックレベル要素
- 共通の属性
- 全ての要素が持つことができる。
- id属性:文書内で一意なID
- class属性:その要素が属するクラス、要素のメタデータとしての役割
第十一章 microformats
microformatsは人間が読んで理解できるWebページの意味をプログラムからも処理できるように形式的に意味を記述するための技術で、HTMLの中でさらに意味のあるデータを表現するための技術
microformatsの分類
elemental microformats
リンク関係を使って要素のメタデータを表現するフォーマット
- rel-license
- <a>要素のrel属性の値にlicenseを追加し、リンクの参照先が参照元のページのライセンス情報であることを示す。
- rel-nofollow
- Googleの検索エンジンが参照リンク数を検索順位の重み付けに利用している仕組みを悪用して機械的に自分のサイトへのリンクを増やすスパム防止のためのリンク。
- リンクにrel = "nofollow"がつくように実装することで検索エンジンはこのリンクを重み付けに利用しない。
compound microformats
class属性を使って階層構造のあるメタデータを表現するフォーマット
- hCalender
- イベント情報を記述するためのmicroformats
- 例えばclass属性の値がeventの<ul>要素はこの要素全体でイベント情報を表現することを意味し、その詳細を子要素や孫要素に対して記述する。
- hAtom
- Atom(次章で説明)が持つメタデータをHTMLに埋め込むmicroformats
- 個々のエントリ(entry)とエントリのタイトル(entry/title)、エントリの更新日時(entry/updated)は必須
- entryの子要素にentry/titleやentry-contentを入れる形で記述する。
microformatsの問題点
classやrelの属性値だけでメタデータを表現するため、同じWebページに同じclassやrel属性があるとプログラムの誤動作やmicroformatsが作れないといったことにつながってしまう。
第十二章 Atom
AtomはRFC4287が規定するXMLフォーマット。様々なWebサービスのWeb APIとして利用できる。
Atomのリソースモデル
メンバリソース:最小のリソース単位(一つ一つの記事や画像)
- エントリリソース:エントリで表現するメンバ
- メディアリンクリソース:エントリリソースのうち、メディアリソースへのチンクを持つもの
- メディアリソース:テキスト以外のデータ、マルチメディアスタイル
コレクションリソース
- メンバリソースを複数含む。
- コレクションリソースは階層化できない。
- <feed>要素で表現
拡張子と名前空間
- 拡張子「.atom」
- 名前空間「
http://www.w3.org/2005/Atom
」 - 拡張要素はまた別々の名前空間に属する。
エントリ
エントリリソースの表現
メタデータ
ここではメタデータの中で必須であるID、タイトル、著者、更新日時を紹介。
- エントリ
- ID
- <id>タグで示す。
- エントリを一意に示すURI形式のID(tagスキームのURIがよく用いられている。)
- タイトル
- エントリの概要を示す<summary>要素がある。
- type属性として「text」「html」「xhtml」を持つ。
- デフォルトでは「text」
- 著者
- 貢献者を示す<contributor>要素もある。
- それぞれの要素は<name>要素を必須で持つ。
- <uri>要素や<email>要素を任意で持つ。
- 更新日時
- 公開日時を指す<published>要素がある。
- RFC3339で規定された日時フォーマット
- ID
その他にもカテゴリ要素やリンク要素もある。
エントリ内容(<content>タグ)
- メディアタイプ
- 基本的に「text」「html」「xhtml」の3つの属性
- 「application/xml」「+xml」の場合、<content>要素は直接XML要素を含むことができる。
- テキスト以外でもtext/csvやimage/jpegなどを入れることができる。
- 巨大な画像や映像はsrc属性で表現するが、src属性で外部リソースを参照しているエントリリソースを「メディアリンクエントリ」と呼ぶ。
- なお、「メディアリンクエントリ」が参照している画像リソースを「メディアリソース」と呼ぶ。
フィード
コレクションリソースの表現
メタデータ
フィード要素も同じメタデータを持ち、必須要素はエントリ要素のメタデータと同じ
なお、authorとcontributorはそれぞれのエントリでのデフォルト値になる。
またフィード独自のメタデータもある。
- サブタイトル
- タイトルで説明しきれない説明を記述。
- 生成プログラム
- フィードを生成したプログラムの情報を記載
アイコンとロゴ
-
アイコン
- faviconを指定。内容はfabiconのURI
-
ロゴ
- フィードを象徴する画像のURI内容として記述する。
Atomの拡張
Atom Threading Extensions(スレッドを表現)
- 接頭辞は「thr」
- <thr:inreply-to>
- replies、thr:count、thr:updated
- <thr:total>
これらを用いて1つのエントリに対して複数の返答が可能なスレッドの表現が可能。
Atom License Extension(ライセンス情報を表現)
- ライセンスリンクを複数持つことができる。
- unspecifiedリンクによってライセンスを指定しないことを明示できる。
- <rights>要素は人が読めるライセンス情報、licenseはプログラム用
Feed Paging and Archiving(フィードを分割する)
数万件ものエントリを1つのフィードで表現することはできないので、この拡張を用いてフィードを分割する。
- 接頭辞は「fh」
- 完全フィード
- 全てのメンバリソースを表現できているフィード
- <feed>直下に<fh:complete>を置く
- ページ化フィード
- エントリをいくつかのページに分割
- first,lastなどでページ間の関係を示すことができる。
- アーカイブ済みフィード
- ブログサービスの月別のアーカイブをフィードで表現。
- エントリの内容が固定されており、フィードごとのエントリの個数にばらつきがあるといった特徴がある。
OpenSearch
OpenSearchは検索エンジンのWeb APIのベースとなる仕様で、様々な検索サービスが活用している。
大きく分けると4つのパートに分かれており
- Description Document
- 検索エンジンが提供する機能をプログラムから理解可能な形式で記述するXML形式
- URL Template Syntax
- 検索結果リソースを表現するURLの検索クエリ部分をパラメータ化する仕様
- Query Element
- URL Template Syntaxで使用する検索パラメータを記述するXML要素。Description Documentと検索結果の両方で利用する。
- Response Element
- 検索結果をAtomなどのフィード形式で表現するための拡張要素
ここではAtomの拡張となる「Response Element」についてのみ紹介する。
- 接頭辞は「os」
- <os:totalResults>:検索結果総数
- <os:startindex>:最初のエントリのインデックス
- <os:itemsPerPage>:最大の検索結果エントリ数
- <os:Query>:検索クエリ
第十三章 Atom Publishing Protocol
AtomPubはAtomが規定したフィードやエントリで表現するリソースの編集、いわゆるCRUD操作を実現するためのプロトコル
AtomPubのリソースモデル
AtomPubではコレクションリソースの上にコレクションのメタデータを表現するサービス文書とエントリのカテゴリに指定できる値を列挙するカテゴリ文書を追加する。
メンバリソースの操作
エントリ単位での操作
フィードに含まれている各エントリは固有のURIを持っている。それぞれのURIにHTTPメソッドを適用すればCRUD操作が実現できる。クライアントはこの編集用URIを<link>要素のrel属性にeditという値を持たせることで見つけている。これにより、GET、POST、DELETE、PUTといった各HTTPメソッドを実現している。
- GET:リンクの取得
- PUT:クライアントは取得したエントリを編集し、サーバにPUTすることでエントリの情報を更新
- DELETE:エントリの削除
- POST:コレクションリソースにPOSTすることによってリソースの作成を行う。
メディアリソースの操作
画像本体のPOSTを考える。
- リクエストのSlugヘッダに投稿するメディアリソースのURIやタイトルに使うヒントとなる文字列を%エンコードしたものが入る。
- リクエストに成功すると、locationヘッダにメディアリンクエントリのURIが入り、本文にはメディアリンクエントリが入る。その中にはメディアリソースの編集用URIとメディアリンクエントリ自身の編集用URIが入る。
サービス文書
コレクションリソースのメタデータを複数まとめて記述できるコレクションリソースのリストを集めたホームページのようなもの。
メディアタイプと要素
- メディアタイプはapplication/atomsvc+xml
- <service>要素をルートに持ち、子要素に1つ以上の<workspace>要素がある。この要素は<atom:title>要素を子要素として持つことでタイトルをつけることができる。
- <workspace>は0個以上の<collection>要素を持つ。この要素はタイトル、URI、メディアタイプ、カテゴリがメタデータとして入る。
- カテゴリは外部のカテゴリ文書として表現できる。
第十四章 JSON
JSONはデータ記述言語で、Javascriptの記法でデータを記述できる点が最大の特徴。
データ型
- オブジェクト
- 名前と値の集合(この2つの組をメンバと呼ぶ)
- メンバの名前は常に文字列
- 値は文字列、オブジェクトなどJSONのデータ型であれば何でも入れられる。
- 配列
- []で配列を示す。
- 文字列
- \uXXXXという形式でエスケープ可能
- 数値
- ブーリアン
- リテラルで用意されている。
- null
の6つの型が用意されている。
JSONP
必要な理由
Ajaxで用いるXMLHttpRequestは同じサーバとしか通信できない。これはユーザの知らない間に別の間と通信するクロスドメイン通信を防ぐためである。しかし、これだと自分のサービスでは地図データと郵便番号データを保持できずに、これらを提供している。他のWeb APIから適宜取得することができない。
<script>要素による解決
<script>要素を用いると複数のサイトからJavascriptファイルを読み込める。この要素は通常ブラウザのセキュリティ制限を受けない。
コールバック関数を活用するJSONP
JSONPではオリジナルのJSONをクライアントが指定したコールバック関数名でラップして、ドメインの異なるサーバからデータを取得する。