API BlueprintとdrakovとdreddでAPIドキュメントを書きつつモックサーバを立ててさらにテストを走らせる - 日頃の行い
タイトルの通りのことをやってみました。 どんな時にテストがコケるか等の精査が出来てないのでまた続きを書くことになりそうですが、 とりあえずやってみたメモです。 API Blueprint? API Blueprintはmarkdown形式でドキュメントを書けるweb APIのドキュメンテーションを書く用の言語ですかね。 API Blueprint | API Blueprint この形式で書いて別のツールで、モックサーバを起動したりテストを走らせたり出来るみたいです。 API Blueprint Tools | API Blueprint drakov? drakovはblueprintの形式で書かれたファイルを利用してモックサーバを起動できるツールです。 github.com API Blueprintとでググるとapi-mockというものがよく出てきたんですが、 最近メンテされてないよ
API Blueprintで書いたWeb APIをdreddでテストする - Qiita
前々回：API BlueprintでWeb APIのドキュメントを生成する - Qiita 前回：API Blueprintとapi-mockでモックサーバを作成する - Qiita 概要 さて、今回はAPI Blueprintを使って作成したWeb APIがドキュメント通りに動作するかを、dreddを使ってテストします。 dreddとは dreddはAPI BlueprintをベースにしたWeb APIのテストフレームワークです。"Language-agnostic"と謳っているだけあってテストのフックにはnode.js以外にもgoやPython、Rubyなど多様な言語が利用でき、またCircleCIやJenkinsCIなどのCIのサポートもあります。 このように、API Blueprintのエコシステムに乗っかることによって、API Blueprint形式で書いた仕様からaglioを使
APIドキュメントを支える技術 - Qiita
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
API Blueprintとその周辺ツール - Qiita
APIを作る機会が増えてきている 例えばマイクロサービス間はAPIでやりとりすることが多い。 外部のサービスもだいたいAPIでやりとりする。 社内APIもいくつかあるが、いざ使おうとなるとどんなリクエストを送るべきなのか、またどんなリクエストが返ってくるのかを調べるのが面倒。 API ドキュメントを書くのは大変 フォーマットは？ Markdown? HTML? Text? エンジニア間で書き方がバラバラにならない？ そのドキュメントの内容は今も正しい？ そもそも書くのが面倒… ということで、いい感じのAPIドキュメントツールがほしい API ドキュメントツールに求めること その1 ドキュメントが書きやすい ドキュメントが読みやすい ドキュメントがGitで管理しやすい リクエスト情報、レスポンス情報が見やすい curlですぐに試せるようにサンプルがほしい ドキュメントとコードに乖離がないよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
