クライアント向けインターフェースの実装(1)

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
好きな料理は?と聞かれたら、カレーと即答する、たなけんです。
本エントリでは、プレゼンテーション層とアプリケーション層とをつなぐ、クライアント向けインターフェースの実装について記載します。

クライアント向けインターフェースの実装(1)

プロジェクトファイル

Compojure ver 1.1.0の利用を追記しました
またleiningenからringアプリケーションを起動出来るよう:ringオプションを追記しました。

nsマクロ

compojure.coreとcompojure.routeの利用を追記しました。

仮実装

httpクライアントからアクセスを可能にするためurlと関数を結びつけました。

テストコード

正常系、以上系の処理の2パターンを追加しました。

対応するAPIを増やす(準備)

これまでDictionary.comのdefine/dictionaryのみを対象に、url構築からjson-文字列抽出を実装しましたが、Dictionary.comではdefinition/dictionary以外にも様々なAPIを提供されています。
そこで、折角ですのでdefine/dictionary以外のAPIにも対応できるよう、これまで実装した関数に変更を加えようと思います。(修正に伴い、関数ごとの機能の切り分けなど、プログラムの見通しも良くしたいと思います。)
表1: Dictionary.comのAPI一覧

	サービス名	type	site
	Dictionary (英英辞書)	define	dictionary(任意)
	Thesaurus (分類語彙辞書)	define	thesaurus(任意)
	Slang (俗語辞書)	define	slang(任意)
	Etymology (語源)	無し	etymology
	Example (例文)	example	無し
	Questions and Answers (Q&A)	無し	questionanswer
	Synonyms (同義語)	synonyms	無し
	Random (ランダム)	random	dictionary(任意)
			random	thesaurus(任意)
	Spelling (綴り字)	spelling	無し

まずはhttpリクエストのパラメータについて整理します。
英英辞典、分類語彙辞書、俗語辞書、ランダムについては、同じ引数でurlを組み立てることができます。(ただしsiteは省略可能、省略時にはdictionaryが指定されます)
しかし例文、同義語、綴り時については上記とは異なり引数にsiteを取りません。また、語源とQ&Aについては、引数にsiteを取らない代わりにtypeを取ります。
つまり、urlのパターンは以下のようになります。

• typeにdefineが指定される
• typeにdefineが指定され、siteにdictionaryが指定される
• typeにdefineが指定され、siteにthesaurusが指定される
• typeにdefineが指定され、siteにslangが指定される
• siteにetymologyが指定る
• typeにsynonymsが指定される
• typeにrandomが指定される
• typeにrandomが指定され、siteにdictionaryが指定される
• typeにrandomが指定され、siteにthesaurusが指定される
• typeにspellingが指定される

現時点では、引数が固定のため、語源、例文、Q&A、同義語、綴り時のサービスに対応していません。また、レスポンスとして返されるxmlのフォーマットも異なるため、各サービスごとにxpathを変更する必要があります。
つまり、対応APIを増やす為に必要な修正点は以下となります。

• interface-for-clientで呼び出しサービスを識別
• 利用するAPIに対応したurlを構築
• 利用するAPIに対応したxmlからのJSON文字列の生成

今回の作業は以上。最後までお読み頂きありがとうございました。

たなけん (作業時間30分)