「Webを支える技術 -HTTP、URI、HTML、そしてREST」山本陽平(技術評論社 WEB+DB PRESS plus) を読んで、RESTfulなWebサービスのリソース設計を自分でもやってみようと
思い立ちました。
とはいえ、本に記載されている郵便番号検索サービスをまねして作ってみるだけでは全く芸がないので、和暦検索サービスを考えてみたいと思います。中期連載(?)になるかと思いますので、のんびりとお付き合い願います。
ということで、まずは簡単に構想を練ってみます。
Googleを検索すると、既にいろいろと和暦<->西暦の検索あるいは変換サービスがあるようです。
しかしこれらのサイトでは、RESTで最も重要なアドレス可能性(※)が実現されていません。
実はWikipedeaでは
の形で、アドレス可能性が実現されています。しかし、和暦->西暦への変換は元号の後の年を指定できませんし、基本的には人間が読むことを想定したフォーマットでしか提供されておらず、JSONP等でマッシュアップし易いサービスとはなっていません。
なお、和暦には
- １年の中で複数の元号が存在する(昭和64年と平成元年など)
- 南北朝時代には２系統の元号が存在する
- 元号の読みに同音が存在する(URIにローマ字表記を単純には使用できない)
- 未来の元号が不明(西暦2050年は平成で良いのか？など)
また、過去分のデータは確定しているので最初は読み取り専用のサービスとして設計できるという利点もあります。
ということで、最初の構想の結論としての方針です。
- RESTを満たす和暦検索Webサービスを作ってみる
- 主眼はWebサービスの(リソース)設計を学習とする
- 見た目、実装、デプロイはできるだけ簡易に済ます(多分GAE Python)
- コンピュータが使いやすい形式でも提供する(Wikipediaや他サイトとの差別化)
(※)アドレス可能性
URIでリソースを一意に特定可能であること。Wikipediaの例のようにアドレスで特定の情報が指定できることです。例に挙げた和暦検索サービスはそのような構造にはなっておらず、どの検索結果でも同じURIが割り振られています。
0 件のコメント:
コメントを投稿