「東京メトロオープンデータ活用コンテスト」②APIの仕様設計を理解し、ドキュメント化する - Qiita
成果物：apiary.ioによる、APIドキュメント とりあえず見て貰えるとイメージつかみやすいです↑ あらすじ 100万円欲しいのでAPIを利用したアプリ開発を学ぶ絶好の機会なので、東京メトロオープンデータ活用コンテストに挑戦しようとしている。 前回、とりあえずざっと触ってみてAPIのイメージは掴んだ 今回は、公式ドキュメントと実際のレスポンスを咀嚼して、仕様設計を汎用ドキュメント化しつつ理解していくことを目的とする せっかくドキュメント化するからには、汎用性と実用性が高いフォーマットとしたい（オレオレにはしたくない） 成果物 API Blueprintで記述されたテキストをApiary.ioでホスティングし、以下を作った TokyoMetroOpendataAPI · Apiary github上のソース（markdownプレビュー版） やってみてわかった、ApiaryによるAPIドキ
APIドキュメントを実装と乖離させないために - Qiita
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
