前々回：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を使
この記事はGoCon 2016 springで話す内容を圧縮するためのものです。 WebサービスのAPI仕様を記述したりするためのそれなりに有名な仕様について、筆者(@vvakame)の私見を述べていく。 なお、Google Trendの結果を見ると…。 仕様を調べてSwaggerを選択する事にしたのは1年弱程度前のはずなので、もし "今はそれもうできるよ！" とかあったらコメントなどで教えてください。 RAML RESTful API Modeling Language なので、手書きを前提にしている。 YAMLで頑張って仕様を書く。 Spec APIs Explorerっぽいものもあるっぽい。 総評 比較的広く使われているようでパワを感じる。 まず仕様が先というスタイルなのがめんどくさそう。 YAMLなのがちょっとイヤ。 RAMLからGoとJavaScript(TypeScript)向
成果物：apiary.ioによる、APIドキュメント とりあえず見て貰えるとイメージつかみやすいです↑ あらすじ 100万円欲しいのでAPIを利用したアプリ開発を学ぶ絶好の機会なので、東京メトロオープンデータ活用コンテストに挑戦しようとしている。 前回、とりあえずざっと触ってみてAPIのイメージは掴んだ 今回は、公式ドキュメントと実際のレスポンスを咀嚼して、仕様設計を汎用ドキュメント化しつつ理解していくことを目的とする せっかくドキュメント化するからには、汎用性と実用性が高いフォーマットとしたい（オレオレにはしたくない） 成果物 API Blueprintで記述されたテキストをApiary.ioでホスティングし、以下を作った TokyoMetroOpendataAPI · Apiary github上のソース（markdownプレビュー版） やってみてわかった、ApiaryによるAPIドキ
概要 アプリの開発を進めるには、APIの仕様 + API仕様通りのレスポンスを返すモックがあると捗る モックを簡単に効率良く作成する方法を調査 調査・検証 1.自分で仕様から書き起こす 長所 好きな言語で書ける 普段書かない言語を選択すればスキルアップ 短所 地味に大変 実際に使うときが面倒(ローカルか開発サーバ) 使いまわせない 時間がかかる 仕様変更ごとにコードを修正 2.JSONSchemaからの生成 長所 JSON SchemaでAPIを設計することでfieldの型など仕様が明確になる。 APIのレスポンスが正しいかValidationするのに使える。 サーバ、クライアントどちらでもテストに使用できる ドキュメントを自動生成できる。 短所 書くのが大変 json_worldというRubyのDSLでJSON Schemaが書けるgemがある 参考 http://r7kamura.ha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
