Protocol Oriented WebAPI Abstraction | try! Swift Tokyo 2018 Day1-13

今やスタンドアロンで動くiOSアプリは数少なく、ほとんどのアプリではWebAPIを経由してサーバーと情報のやり取りを行います。アプリの動作の根幹となるAPI通信を適切に設計し、将来の改修や通信/マッピングライブラリの入れ替えなどをより容易にするためのプロトコル指向なAPI定義の仕方と、さらにそれとRxSwiftを組み合わせた型安全なAPI抽象レイヤーの設計について紹介します。また、ここで話す内容をフレームワーク化したAbstractionKitの紹介をします。

Protocol Oriented WebAPI Abstraction

f:id:niwatako:20180301165638j:plain

f:id:niwatako:20180301165810j:plain

みなさんエンドポイントをどのように書いていますか

BaseURL, Path, レスポンスなど。

API定義が通信フレームワークから独立しているのが良いでしょう。

SwaggerからSwiftコードを自動生成する時に、ネットワークフレームワークと分離したシンプルなコードを出力できます

そこでAbstractionKitをつくりました

f:id:niwatako:20180301165905j:plain

JSON構造をGenericで表せます。

一つだけの場合

f:id:niwatako:20180301165940j:plain

配列の場合

f:id:niwatako:20180301165957j:plain

パース不要の場合(ResultはVoid)

f:id:niwatako:20180301170013j:plain

合成されたレスポンスも。タプルで変える。

f:id:niwatako:20180301170031j:plain

f:id:niwatako:20180301170053j:plain

Response型はResponseDefinitionに準拠していてAssociatedTypeでレスポンスなどを指定する

f:id:niwatako:20180301170130j:plain

Articleが返るのがわかる

f:id:niwatako:20180301170149j:plain

APIKitのRequestにするために

f:id:niwatako:20180301170153j:plain

Singleにするために

f:id:niwatako:20180301170216j:plain

上位レイヤーから使うためにラッパーを書く

f:id:niwatako:20180301170234j:plain

新しいエンドポイント追加も容易。APIKitに依存する箇所が少なく疎結合

f:id:niwatako:20180301170300j:plain

f:id:niwatako:20180301170332j:plain

[広告]面白かったら、ためになったら

  • はてなブックマークSwift タグをつけてブックマーク!
  • 「インターネットで生活を楽しく豊かにしたい」仲間を募集しています
  • Bitcoin: 3KGqXtR1ZaGVdkvcw8CCNrkDxDhdbZBYHL