2016の19日目の記事です。Schemaを楽に書ける+人が読めるドキュメントが生成できるメンテされていない事が検出できるので続く(はずAPI作成時のリクエスト・レスポンス形式問題サーバとクライアントで並行開発しながらAPIを作成する場合、以下のようにリクエスト・レスポンス形式を整えにくいという問題があります。以下の2つを保証する必要があり、何のサポートなしに維持するのはとても大変です。Schema+committee+prmdを導入することで、この問題を大幅に解決できます。SchemaとはJSONを用いてデータを記述する際の形式の1つで、主にアノテーションやバリデーションを目的としているものらしいです。/v1/friendsが、access_tokenをパラメータとして必ず取り、戻り値には必ずfriendsとreccommendsというキーが含まれているという事を定義できます。friendsとreccomendsの具体的な内容については別に定義して読み込みますが、同じ景色であるということも表現しています。同じデータなのに人によって違う構造になるような問題をを解決しやすくなります。Schema自体はただの形式なのでそれ自体は特に何も無いですが、統一された形式になるため、容易にプログラムから処理を行う事ができます。rubygemのcommitteeはその発想に沿ったものです。Schemaを読み込ませることで、リクエストやレスポンスが定義にそっているかをチェック、そっていない場合にエラーにするなどの処理を行います。テストにおいても形式が正しいかをチェックできます。Schemaの形式と実際の形式とがそろっていることを保証できます。日付フォーマットの文字列をdatetimeに変換、GETリクエストの時に文字列を数値に変換してくれたりと色々な便利機能があります。Schemaとcommitteeを利用することで、以下が可能になります。Schemaに沿っているか自動チェック&変換できるこれで、当初の問題だったドキュメントが実装と乖離していく問題は大幅に解決が可能ですが、代わりに以下の問題が出てきます。Schemaを人間が読むのもつらいJSONは人間が直接読み書きするドキュメントには(たぶん)適さないです。Schemaを作成するのがとても大変になってしまいます。それを解決するのがprmdです。Schemaを元に人間が読めるmarkdownドキュメントを生成できるgemです。Schemaを出力できます。#/definitions/user/definitions/friendsまた、マークダウンのドキュメントも以下のように出してくれます。Schemaを人間が読み書きできるようになります。Schemaの利点を最大限活用できると思います。平行して開発を行っても手戻りやコミュニケーションロスを大幅に減らせます。全体としては以下の図のように動いています。まとめ解決すること正しく導入することで以下の問題を解決できます。以下の問題は解決しません。以下のような問題が出ており、解決方法を模索中です。Schema+committee+prmdは全てを解決するものではありませんが、クライアント・サーバ間の形式という、認識の齟齬が起こりやすい境界の部分にはとても効果がある組み合わせでした。ota42yC++/Ruby/RoR/golang/rust/flutter。