「Webを支える技術」まとめ（第１部〜第３部）の続きになります。

第十章 HTML（Hyper Text Markup Language）

HTMLのメディアタイプ

text/html：SGMLベース
　SGMLはマークアップ言語の１つで過去のHTMLはこの言語をベースに作られていた。
application/xhtml+xml：XMLベース

文字エンコーディングはUTF-8を使うのが無難と言える。

XMLの基礎知識

XML文書は木構造として表現できる。

html
- head
  - title
- body
  - h1
  - p

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で規定された日時フォーマット

その他にもカテゴリ要素やリンク要素もある。

エントリ内容(<content>タグ)

メディアタイプ
- 基本的に「text」「html」「xhtml」の３つの属性
- 「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>

これらを用いて１つのエントリに対して複数の返答が可能なスレッドの表現が可能。

Atom License Extension（ライセンス情報を表現）

ライセンスリンクを複数持つことができる。
unspecifiedリンクによってライセンスを指定しないことを明示できる。
<rights>要素は人が読めるライセンス情報、licenseはプログラム用

Feed Paging and Archiving（フィードを分割する）

数万件ものエントリを１つのフィードで表現することはできないので、この拡張を用いてフィードを分割する。

接頭辞は「fh」
完全フィード
- 全てのメンバリソースを表現できているフィード
- <feed>直下に<fh:complete>を置く
ページ化フィード
- エントリをいくつかのページに分割
- first,lastなどでページ間の関係を示すことができる。
アーカイブ済みフィード
- ブログサービスの月別のアーカイブをフィードで表現。
- エントリの内容が固定されており、フィードごとのエントリの個数にばらつきがあるといった特徴がある。

OpenSearch

OpenSearchは検索エンジンのWeb APIのベースとなる仕様で、様々な検索サービスが活用している。
大きく分けると４つのパートに分かれており

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>要素をルートに持ち、子要素に１つ以上の<workspace>要素がある。この要素は<atom:title>要素を子要素として持つことでタイトルをつけることができる。
<workspace>は0個以上の<collection>要素を持つ。この要素はタイトル、URI、メディアタイプ、カテゴリがメタデータとして入る。
カテゴリは外部のカテゴリ文書として表現できる。

第十四章 JSON

JSONはデータ記述言語で、Javascriptの記法でデータを記述できる点が最大の特徴。

データ型

オブジェクト
- 名前と値の集合（この２つの組をメンバと呼ぶ）
- メンバの名前は常に文字列
- 値は文字列、オブジェクトなどJSONのデータ型であれば何でも入れられる。
配列
- []で配列を示す。
文字列
- \uXXXXという形式でエスケープ可能
数値
ブーリアン
- リテラルで用意されている。
null

の６つの型が用意されている。

JSONP

必要な理由

Ajaxで用いるXMLHttpRequestは同じサーバとしか通信できない。これはユーザの知らない間に別の間と通信するクロスドメイン通信を防ぐためである。しかし、これだと自分のサービスでは地図データと郵便番号データを保持できずに、これらを提供している。他のWeb APIから適宜取得することができない。

<script>要素による解決

コールバック関数を活用するJSONP

JSONPではオリジナルのJSONをクライアントが指定したコールバック関数名でラップして、ドメインの異なるサーバからデータを取得する。