商品情報のJSON表現について考えた

キープリストで提供するリソースのURI

キープリストというWebアプリを作ろうとしています。気になる商品（Amazonで扱っているもの）を放り込んでおけるサービスです。

以前の日記では、URIの設計について考えました。それからも断続的に考えていて、現在は以下のようにしようと思っています。

リソース	URI
トップレベルリソース	http://keeplist.in/
商品検索結果リソース	http://keeplist.in/amazonsearch?q={キーワード}&format={html または json}
商品リソース	http://keeplist.in/Item:{ASIN}.{html または json}

本当はもっとたくさんのリソースが必要ですが、書き込み可能なWebサービスの設計は高難度なので、まずは読み取り専用部分のみ考えることにします。

さて、『Webを支える技術』で紹介されているROA（リソース指向アーキテクチャ）の設計手法に従えば、URI設計に続いてリソース表現の設計フェーズとなります。

どこから手を付けようか迷ったのですが、もっとも重要な商品リソースの、もっとも簡素なJSON表現から考えることにしました。

商品情報のJSON表現

microformatsには、商品情報を表現するhProductと、集計レビュー情報を表現するhReview-aggregateがあります。これらになるべく従うことにしました。

従うといっても、いずれもドラフト段階のフォーマットですし、microformats自体、JSONへの変換方法が明確に定義されていないので、どういう表現を提供するのか、結局は自分で考える必要があります。

試行錯誤してできたのが下記のJSON表現です。

迷った点

現在のドラフトでは、hReview-aggregate には item プロパティが必須なのですが、あえて無視しました。hProduct の review プロパティとして包含されているのですから、どの商品に対するレビューなのかは自明だからです。

最初は hProduct と hReview-aggregate を並列させて、Include Pattern でインクルードさせようかと思ったのですが、JSONでどう表現したらよいか分からなかったのでやめました。

hReview-aggregate に hProduct を包含させる方法も考えられますが、レビュー情報はおまけなので、コンテナにするのは無理がある気がします。Containers に関する議論が深まっていけば、このあたりの問題が解決されるのかもしれません。

表現例の改訂履歴

• 表現例をgistに移行しました（2010-06-01）
• hProduct から外れる商品情報（binding、creators など）を item-detail プロパティにまとめていましたが、まとめる必要がなかったので、ばらしました（2010-06-01）