fresh digitable

めんどくさかったなってことを振り返ったり振り返らなかったりするための記録

Retrofitで実装したREST APIのinterfaceクラスを何かで包んで使ったらいい感じ

Retrofitを使って定義したREST APIのinterfaceは何かで包んでからRepositoryとかに渡すのがいい、という話。Retrofitに限らず何か特定ののREST APIにアクセスするライブラリを使うときにも有効ではないかと思う。そのようにするモチベーションを次の通り述べる。私はRestClientみたいな名前のクラスに包んでいる。

共通の処理を注入する

REST APIへのアクセスはいろんな画面で起きるので、エラーレスポンスのハンドリングも素直にやると画面ごとに実装しなければならなくなる。 例えば、レスポンスが返ってこないときはいつも決まったメッセージを出すとか、そういった共通の処理はなにかの形でまとめたい。 そのような用途のために、エラーレスポンスが返ってきたときの共通処理や、エラーレスポンスをイベントに変換してどこかに流すPublisherやChannel的なものを用意してRestClientに注入する。

リストデータの取得方法を隠蔽する

リストデータを取得するREST APIでは2ページ目以降を取得するときにトークンが必要になることがある。 このトークンは1ページ目のレスポンスの中にリストデータと一緒に含まれている。 2ページ目を取得するときまでは何らかの形で覚えておかなければならない。 そのような時、メモリ上に保持しておけばいいというような場合はRestClientで保持していればよい。 RestClientの利用者はトークンを意識することなく次のページを取得できる。次のページを取得する方法を隠蔽しているので、REST側がランダムアクセス的なインタフェースに変わったとしても(あるいはランダムアクセス的なインタフェースからトークン方式に変わったとしても)RestClientの利用者は処理を変える必要がない。 トークンをシリアライズしたいというときには一工夫する必要があるかもしれない。

ライブラリとアプリとの境界を規定する

シンプルに見ればライブラリとアプリとの間にレイヤーを挟む格好になるので、腐敗防止層的な役割もやってくれる(Retrofitが腐敗してしまうのは考えたくないけど)。 また、REST API側が開発中で完成していない場合や、まだバギーな時も代わりの値を返すようなものを差し込みやすいかもしれない。Repositoryのテストもいくらか楽になるかもしれない。