状態管理できるRuby製HTTPクライアントライブラリ Faraday 紹介 #RubyKaigi #RubyKaigiB
tkawa「まとめ。動的に処理することで疎結合にできる。また、アプリケーション/ドメイン固有の部分を切り出し、標準規格に沿って設計するとその部分は汎用ライブラリが使えるので再利用性が増す。」#rubykaigiB #rubykaigi
2016-09-10 11:16:51GitHub APIのResponseに含まれるURLは何に使えばいいかわからなかったんだけど このためにあったのか! #rubykaigiB
2016-09-10 11:16:53動画見ると良さそうに見える。web clientがステート持ってるのは面白い。こんな感じのAndroid web clientちょっと検討してみたい。 #rubykaigiB
2016-09-10 11:16:57発表終了、時間いっぱいなので質疑応答なし。めっちゃいい発表だった。 #rubykaigi #rubykaigiB
2016-09-10 11:17:14多分似たようなことが aws-sdk の version 1 で実現されていたんだけど、 aws-sdk version 2 では切り捨てられていて、わかるし便利そうで素敵なんだけどつらいんだよね、みたいなのはある #rubykaigiB
2016-09-10 11:18:02実際のAPIでいろいろためしてみると穴も出てきそうではあるな。あとはAPIレスポンスサイズの肥大化も気になるけど、まぁGithubで返してるんだしそこは問題になるサイズではないか。 #rubykaigi #rubykaigiB
2016-09-10 11:18:42最初のエンドポイントにアクセスしてもらった LInk の中からアクセス可能なAPIエンドポイントを選択して遷移するようにすればサーバ側のURL構成から疎結合に出来るって理解であってるのかな。面白い。#rubykaigiB
2016-09-10 11:20:05その世界では、最初のエンドポイントのURLだけを知っておけばよくて、それ以外のURL変更に関してはユーザはケアしてよくなると。でも ref の意味や引数の仕様からは解放されない気もする。#rubykaigiB
2016-09-10 11:21:39Faradayっていろんな箇所で見るけどどういう物なのかよく分かった。これからはRestClientをすぐに使わず少し考えてみよう #rubykaigiB
2016-09-10 11:22:33というかさっきの発表で一番参考にすべきは、「APIを作るときにGithub APIのように関連APIのURIを返しておくと、クライアント側での選択肢が広まる」ことだな。自分が使うかはともかく、利用者の選択の幅は広いほうが良い #rubykaigi #rubykaigiB
2016-09-10 11:23:02新しくAPI作るなら、Link Header Fieldで返すか、レスポンスボディで返すか。前者のほうが規格に則っててインターフェイスが統一できるけど、現行のクライアントで扱うなら後者の方が楽そう。両方って手もあるけど、肥大化しそう。 #rubykaigi #rubykaigiB
2016-09-10 11:25:57#rubykaigi Web Client の話。2014年のトークの内容のおさらいですら改めて勉強になる。HTTP クライアントが状態を持つと聞くと野心的だが、既存の実装と標準仕様を研究して上手に再利用し、さまざまな面で素晴らしい仕事。最終日これだけのためでも来た甲斐あった。
2016-09-10 11:32:53