APIやJSON-RPCなどのバックエンドとモバイルアプリ間の通信を実装する案件はおそらく昨今非常に多いかと思われます。弊社もJSON-RPCを裏方に持ち、iOSとAndroidアプリ、もしくはフロントのWebがそれを呼び出す仕組みを持っています。APIやRPCを呼び出すための「ルール」をどのようにお互いの技術者が共有するか?は僕らの課題でもありました。そのルールとしてリクエストパラメータパラーメータごとの型やお約束リクエストのサンプルレスポンスの値サンプルリクエストに対するレスポンスなどがドキュメント化されていると便利でしょう。それは「手で仕様書を書く」という一点張りで解決出来ることではありますが、日々追加、修正されるAPIに対しては効率が悪いと感じてしまいます。」というライブラリしいては「概念」を見つけました。氏が作ったRubyのライブラリです。https://github.com/r7kamura/autodocRails/Rackのアプリケーションに対して、リクエストを送るテストを書くと、上記で上げたようなリクエストパラメータやレスポンスの情報がMarkdown形式でドキュメントとして保存されます。APIのアプリケーションでは呼び出しとそれに対するレスポンスが一目瞭然というわけです。APIとかのドキュメントを履いてくれるってことで、こんな効果があります。ありますが、僕は僕で自らのプロダクトで使うために「Shodo」というライブラリをつくりました。利点である、仕様の共有を楽にするってことと、テストを必然的に書くようになるという恩恵を受けることになりました。実際、iOS/Androidアプリの開発はパートナー会社のエンジニアさんとやっているのですが、GitHubのプライベートレポ内にあるドキュメントのURLを教えているため、仕様に関する議論は最低限で済みます。Test::JSON::RPC::Autodocはい。以上、前置き終わりです。」をリリースした件です。呼ばれるJSONに対するデータ定義を用いる手法も取られています。自信を仕様とみなしドキュメントを生成したり、データのバリデーションルールを統一化する流れです。氏のBlog記事が分かりやすいですね。};$test->write('sample.md');done_testing();このように使います。メソッドでRPCをコールする際のパラメータを定義します。内部でData::Validatorを使っているのでそれに近い記法でルールを書きます。メソッドで実際のレスポンスが正しく返却されているかもテストします。メソッドを追加してレスポンスボディを簡単にJSONからPerl-Objectへ変換出来るようにしました。メソッドを使って予め指定していたドキュメントルートへMarkdownファイルを書き出すことが可能です。そのMarkdownをGitHubで見ると以下のような見栄えになります。先ほどCPANinzeしたばかりで、これから弊社プロダクトで使っていくところです。