この講演では、私たちのiOSアプリの1つを動かすためにSwiftでWeb APIを構築した経験を共有します。既存のインフラとWebサービスをSwiftでどのように書きかえたのかを説明します。SwiftでのWebサービス構築に必要なことと、ハイパーメディアと宣言型プログラミングを活用して長年進化していけるAPIを設計し利用する方法を探ります。
SwiftのWeb APIとアプリをともに構築する
良いAPIとは
実装が漏れ出ない
ページネーションが必要になる
個々のページの投稿を取得出来る
このような形でAPIがデザインされています。
次のページを要求する前にページが変わってしまう場合、内容が重複します
この問題をどう解決すべきでしょう。クライアント側で回避もできますが、API側で対応することもできます。
idによってそれよりも前の投稿を取得する。
ではこの変更をどう導入すべきでしょうか
APIを分けてしまう方法がよくあります。
バージョニングをパスに用意する。
既存のAPIのデザインを残していくということも残していくことが難しいわけです。APIが上手く機能していくことが必要になります。あるいは古いバージョンをサポートすることですが、実装の詳細を露呈せずにAPIを提供できるならこの問題を解決できます。
Restはサーバーとクライアントが独自に変化していくことを想定する
HypermediaはRESTの重要な部分で進化性を担保します
状態遷移を内部で探すことも出来る。アプリケーションを使ってすぐに新機能を提供できアプリケーションを将来的に変えなくて良くなる。
標準化タイプ
例えば投稿者であれば削除ができます
クライアントはデザイン上、DeleteAfordanceが存在するかを先にチェックする。存在するかと誰が可能化を切り分けることが出来る。
クライアントがビジネスロジックを気にしなくなる。
HyperMediaを使うことで分離ができる
言語の変更に加えて実装を行う時にクライアントを壊さない
FrameworkにはKitura、Vaporがあります。
KituraはIBMのプロダクトなので非常に強いバックです。
私はFrankを使いました。軽量フレームワークです。
Frankはドメインに特化している。
様々な変化が起きています。AppleでWorkingGroupもできています。
新しい対処も生まれるかと思います。
Swift環境においてWeb環境の作り方をリストしたので後でみて下さい。
コードは割愛してテスト、モニタリングの組み合わせもお話します。
定義して実装してAPI Descriptionを使ってテストできる。
Herokuが最もシンプルでコードを投げればOKです。
パッケージを作って依存性無く使うことができます。
Swiftバージョンも指定できます。
コマンドラインツールで実行できます。
それ以外のオプションはIBMのBluemixです。
Dockerを使うこともできます。
マニュアルでデプロイすることもできます。
デプロイしたらモニタリングしたくなります。
たとえばPapertrailで特定のインシデントをみていくことが出来る。
WebAPIは正しくデザインすることが大事です。 言語に依存しない形で人気のツールを使うのが良いでしょう。 モニタリングの話もしました。 APIライフサイクル全体の話をしました。明日はプログラミングの部分のお話もあると思います。
Resource
Q&A
オススメフレームワークは
Sorry couldn'n write (XωX)
APIドキュメンテーションのお話が途中で出てきました。サンプルでAPI Blueprintが出ていましたが他にも色々Specがあると思いますがおすすめはありますか
APIが既に構築されていたらswaggerが選ばれている。OpenAPIになっている。
