タオルケット体操

サツバツいんたーねっと

REST APIに消耗したらJSON RPCを試そう

ここしばらく、REST APIって本当に便利なのか? という疑問を持ちながらコーディングしてました。

ですが、今の会社に移り、JSON RPCを利用してAPIを叩くうちに「あ、もうこれでええやん」という悟りを得たのでそういう日記を書きます。

RESTful難しくない?

RESTful思想に則って、頭を絞ってリソース階層を練り、urlパラメーターとpostパラメーターに頭を悩ませ、冪等性とはなんぞやという議論をぶちかましながらAPIを作り上げるのに疲れました。
ベストプラクティス的なものも一応読んだりしたんですが、複雑すぎです。

普通のプログラミング言語と、RDBを操作するSQLの間にインピーダンスミスマッチが存在するように、REST APIのcallにも同じものを感じてしまいます。

ここら辺の問題は GraphQL | A data query language and runtime が解決してくれそうな雰囲気を感じますが、まだ出始めだし、複雑そうだし、実装がNodeしかないしで実用になるにはもう少しかかりそうです。

最適化が難しい

バルク的に更新したいとか、リソース的には分割されてるけど関係性を持っているので一緒に更新したいとか、そういったところを最適化していく際にテクニカルなコーディングを求められたり、非直感的なAPIが出来上がったりすることがままあります。

出来上がるものはHTTPに密結合

しかもそんだけ頑張って組んだ結果、出来上がるのはHTTPに密結合したインターフェースです。
もちろん、ビジネスロジックを綺麗に疎結合にしておけば再利用は容易ですが、どうせならコントローラーそのものを再利用できた方が良いです。

そこでJSON PRC

はい。Pythonです。
Facebookがなんか新しい奴を作ってて、それも良さそうなんですがとりあえず枯れてて簡単な奴を使います。

ついでに、Flaskくらいの気軽さでもって関数の登録をしていけるようなライブラリが必要だと感じたのでババッと作りました。

GitHub - hachibeeDI/py-json-rpc: JSON RPC toolkit for Python

py-json-rcpです。ひねりもクソもない名前ですね。

How to use

Exampleを見ればわかるように、@register のデコレータを使うことでメソッドの登録ができます。
デフォルトでは関数名がそのままkeyになりますが、引数を渡した場合はそちらがkeyになります。

今のところ実装はアホらしいほどシンプルで、keyを元に関数を辞書に保存して、呼ばれたら評価して返すだけです*1
各ネットワークプロトコルに対応するのも簡単です。JSONをパースして、評価した結果を送りつけ合っているだけなので、数行あればあらゆるプロトコルに対応できるでしょう。プロセス間通信でも使えます。
最適化周りも、例えばリストを渡すことで複数の呼び出しを一度のリクエストで行うことも簡単にできます。

今後の展望

とりあえずMQTTとWebSocketに対応させてたいですね。
あと適当に書いたせいでまだ関数名が変なので、そこら辺を修正しておきたいです。なのでまだpypiにはpublishしてないです。

それと、ちゃんと調べてはいないんですが、MessagePack形式でのシリアライズに対応させたらもっとイイ感じになるんじゃね? とか考えてます。

結論

JSON-RPCよくね? 十分じゃね? もっと流行ってもよくね? GraphQLより単純でよくね?

「オマエは全くもってRESTのことをわかってねーよ」というような意見があったらお待ちしてます。

おしまい。

WEB+DB PRESS Vol.88

WEB+DB PRESS Vol.88

  • 作者: 佐々木拓郎,高柳怜士,鶴原翔夢,小野侑一,中村俊介,佐藤春旗,長野雅広,佐々木健一,久保達彦,若山史郎,佐藤太一,伊藤直也,道井俊介,佐藤歩,泉水翔吾,坪内佑樹,海野弘成,西尾泰和,中島聡,はまちや2,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2015/08/22
  • メディア: 大型本
  • この商品を含むブログを見る

*1:HTTPでは常にPOSTを使います