Create mock APIs in secondsMockoon is the easiest and quickest way to design and run mock REST APIs. No remote deployment, no account required, free and open-source.

概要 Windows, Mac, Linuxで動作する REST API モックサーバ 公式ページ https://mockoon.com/ 良かったところ レスポンス内容が簡単に編集できる ステータスコードが簡単に変更できる Swagger v2/OpenAPI v3 (JSON or YAML)のインポートができる GUIで操作できる インストール こちらからダウンロードしてインストール https://mockoon.com/download/ または Mac なら Homebrew でも可 brew install --cask mockoon 簡単な使い方はこちら https://mockoon.com/tutorials/getting-started/ Swagger v2/OpenAPI v3をインポートして使う サンプルとして Swagger Petstore を使用 h
こんにちは、ソリューション技術部 OTTサービスソリューション統括部 LOGICAプロダクトグループの小川です。 今回はローカル環境で簡単にMock APIサーバを立ち上げることができるアプリケーションをご紹介します。 外部システムと連携する機能を開発する際に検証環境のAPIが叩けない場合にローカル環境でモックサーバを簡単に構築できるツールがないかと探していた際にMockoonと出会いました。 Mockoonを使用するとリクエストとレスポンスの詳細な設定を行うことができます。リクエストヘッダー、クエリパラメータ、BodyデータなどをGUI上で簡単に設定することができ、APIの振る舞いをカスタマイズできるのでとても便利です。 Mockoonとは インストール 固定レスポンスを返すモックの作成 レスポンスのカスタマイズ レスポンスヘッダ リクエスト内容による分岐 動的なレスポンスBody まと
はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか? Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIは golang でフロントエンドを Vue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい!と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
OpenAPI関連のサイト・ツールまとめ2020.10.29 OpenAPI関連のサイトやツールなどの情報が種々雑多にあるので、自分の中での整理と忘備録として残すためにまとめました。(2020年10月時点) 概要OpenAPIとはOpenAPIという表現が使われた場合、恐らくそれらの多くはOpenAPI Specification(以下OAS)に基づいてJSONやYAMLで記述されたREST APIの仕様書(スキーマ)を指しているように思います。 OASはREST APIの仕様を記述するための規格であり、それ自体がなにかのツールやサービスを提供するものではありません。 とはいえ関連するツールやサービスも普及してきているので、あまり言葉の意味を気にしすぎる必要もないかもしれませんが。 OpenAPI Specification (v3.0.3)Implementer’s Draft (OAS
2022/1/31 追記 いまだにこの記事のPVがあるので Rails アプリケーション作るときに参考になりそうなリンクを追記しておきます。 【Rails】もっと早く知りたかったデバッグ用gem 'better_errors','binding_of_caller' | Qiita https://qiita.com/terufumi1122/items/a6f9a939dce25b2d9a3e 【Rails】better_errorsとbinding_of_callerで自分でエラーを解決できるようになろう【初心者向け】 | Qiita - https://qiita.com/ryokky59/items/284892be879996e4f77c Railsにおけるドメイン駆動設計の実践 | linyclar - https://linyclar.github.io/software_d
OpenAPI、正確にはOpenAPI SpecificationはREST APIの定義を記述するための規格です。 つまり、APIサーバがどのような挙動をするのかを記した設計書のようなものです。 2015年末まではSwagger Specificationと呼ばれていたので、こちらの方を知っている方もいるかもしれません。 さて、これがあると何が嬉しいかというといろいろ嬉しいことがあるのですが、主なメリットは次の3点です。 APIを決まったフォーマットで規定できる そのままAPIドキュメントになる API定義からサーバやクライアントのコード生成ができる Swagger時代からSwagger Specificationに関連したツールが出回っており、ツールを利用することで手軽に上記のメリットを享受できるようになっています。 メリット 代表的なツール
<?php /** * @SWG\Swagger( * host="xxxxx.xxx.net:9000", * basePath="/api", * schemes={"http"}, * @SWG\Info( * version="1.0", * title="血圧管理手帳のAPIドキュメント", * ), * @SWG\SecurityScheme( * securityDefinition="MyHeaderAuthentication", * type="basic", * ) * ) * @SWG\Definition( * definition="Blood", * @SWG\Property(property="date",type="string",format="yyyy-MM-dd",description="日付"), * @SWG\Property(propert
はじめに 新しくAPIサーバーを建てるまでの話 新サービスを建てるにあたり考えなければいけないこと 開発を進めるにあたり 言語・フレームワーク・ミドルウェア選定 フレームワークどうするか GraphQLを採用するか、JSONのREST APIにするか サーバー構成をどうするか 構成管理(Infrastructure as a Code) ローカル開発環境はどうするのか CI環境を用意しておくことは重要 コーディング規約や各種規約はどうするのか API仕様作成時の方針について 各環境へのデプロイはどうするのか DDoSやSQLインジェクション対策はどうするのか DDoS対策 CORS, CSRF ミドルウェアの脆弱性 フェイルオーバーの仕組みをどうするか APIサーバーが1台落ちたときに利用者に影響が出ないか 接続先のDBが落ちた時に影響が出ないか サーバー(サービス)監視 ドキュメントをS
今回、サーバ・フロントの完全分業実現のため Swaggerを導入し、APIの仕様を管理、かつモックサーバとして機能させることに。 仕様を決める→モックサーバとして動作させるまでの流れメモ。 動作確認環境 流れ 前準備(brew/npmは入ってる前提) swagger形式のAPI仕様書作成 動作確認環境 Mac OS X以上 Swagger2.0 (Open APIは3.0が最新ですがswagger-codegen使用のため2.0を使用) はやく3.0対応してほしみ。。。 流れ ※色々インストールなどの前準備※ ①API仕様をSwagger形式(yaml)で記載、 ②Swagger-Codegenを使用してnode.jsのプロジェクトへ変換 ③サーバ起動 →モックサーバとしてブラウザ上での確認、 自分のプロジェクトからもレスポンス確認ができる 良いこと: * Githubでyamlファイルの
2018-05-12、OpenAPI Generator が公開されました。 https://github.com/OpenAPITools/openapi-generator OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec これは Swagger Codegen v2.4をフォークしたプロジェクトで、OpenAPIドキュメントから様々なプログラミング言語のAPIクライアントやスタブサーバーなどのソースコードを生成するツールです。まだベータ版のような状態で、“v3.0.0”として初回リリースすることを予定しています 。 私
APIの定義を書く:Excel仕様書はもういやだ RESTful APIを提供するサーバと、そのAPIを利用するクライアント(たとえばSPA)とを並行で開発しようとするとき、まずAPIを定義して、それに基づいてサーバ/クライアント双方の実装を進めようと考えるのは自然だと思う。 そうと決まれば、「API仕様書_20190110.xlsx」と題するファイルを新規作成し、シート別にリソース毎の定義を書き始め・・・てはいけない。せっかくAPIを定義したドキュメントを作成するなら、するのなら、ソースコードの自動生成などの恩恵も受けたい。受けられるはずだ。 少しググってみる。どうやらSwaggerというものを使えばいいらしい。Swaggerに興味を持ったタイミングで、ちょうど書店に平積みになっていた『WEB+DB PRESS Vol.108』の表紙が目に入った。そこには、「スキーマ駆動Web API開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く