3回目となる今回は、サービス間の連携におけるlocalStorageとpostMessageの使いどころについて解説します。localStorageはWeb Storage、postMessageはCross-document messagingまたはWeb MessagingとしてHTML5の仕様に含まれているAPIです。どちらもIE（Internet Explorer）8以降、Firefox 3以降、Safari 4以降と、近年のモダンなブラウザで幅広くサポートされており、iPhone用のSafariやAndroidの標準ブラウザでも使うことができます。
localStorageとCookieの違い
Cookieは一時的にデータを書き込んで保存させるしくみとして長い歴史を持っていますがさまざまな問題を抱えており、使い方には注意する必要があります。ここで取り上げるlocalStorageはCookieの代用手段と見なすこともできますし、実際にCookieの代わりとして使われることもあります。
しかし、CookieにはCookieにしか、localStorageにはlocalStorageにしかできないことがあるのです。
まずはじめに、両者の違いを確認していきましょう。
サーバに送られるデータ
localStorage最大の特徴は、明示的に送信するようなJavaScriptコードを書かない限り、データをサーバへ勝手に送られることがない、ということです。
しかしCookieはHTTPヘッダでサーバに送られてしまいます。Cookieにセットした以上は「サーバからも読み取られる情報である」という認識でサービスを設計する必要があります。これが両者の一番大きな違いです。
localStorageを使う場合、サービス提供者側が知らない、秘密の情報をブラウザに保持させることができます。
Cookieの場合は逆に、ブラウザからは参照することができず、サーバにのみ送信されるという指示をすることができます[1]。
複数ドメインへの送信
複数ドメインにまたがったデータへの送信も、localStorageとCookieで異なります。localStorageに対するアクセスはSameoriginポリシー[2]による制約を受けます。そのドメイン上のlocalStorageに保存されたデータは、同じドメインからでしか参照できません。Sameoriginポリシーによるアクセス制限は、プロトコル（httpかhttps）、ドメイン、ポート番号が一致している必要があります。
これに対して、.example.comに設定されたCookieは、www.example.comにも、www123.example.comにも送信されてしまいます。複数のドメインにまたがって送信する必要がある場合や、有効期限を設定したい場合などには、引き続きCookieが広く使われるでしょう。
ここまでlocalStorageを使うことで、ブラウザ側に「サーバと共有しないデータ」を持つことができる事例を紹介してきました。次の節ではpostMessageを取り上げます。
この記事ではlocalStorageとpostMessageをセットで取り上げています。なぜ異なるAPIを同時に解説するのかというと、localStorageでブラウザ上に保持した「そのドメインの固有データ」へのアクセス制限を、postMessageは意図的に壊して異なるドメイン間でデータを共有できるからです。postMessageを使うことで、異なるドメイン上のJavaScript同士が、サーバを経由せずに直接データをやりとりすることができるようになるのです。
