POSTMANで気軽に始めるAPI-First開発

WEBサービスを作成する機会があるのですが、サービスのインターフェースとなるHTTP RESTのAPIを作ったら、それをテストしなければなりません。これまでのAPIテストでは、主にcURL を使っていました。コマンドラインに URL とパラメータを指定し、結果をファイルにリダイレクト出力、テスト実績を記録するなどしていました。この方式も悪くはないのですが、コマンドプロンプトの黒い画面では飽きてしまいますし、もう少しモダンなテスト方法がないものかと感じていました。 

 

そうした中、とある案件にて、ふたたび WEB API をお客さまに納入する機会に恵まれました。そこで、かねてから目を付けていたWEB APIテストの管理ツール「POSTMAN」を使ってみる事にしました。

 

POSTMAN に目をつけたキッカケは「API テストの生産性を爆上げする」という目的からでした。具体的には下記の要件を満たすツールがあると便利です。

  • API テストを「ステータスコード確認」「イレギュラーテスト」などのようにタイトルを付けて分類管理したい
  • 作成したテストを納入するにあたって、お客さまが簡単にテストを呼び出せるようにしたい
  • 結果は自動でチェックさせたい

結果的に、 POSTMAN はこれら全ての要件を満たしてくれました。
以降で、 いかにしてPOSTMAN が「API テストの生産性を爆上げする」という期待に応えてくれたかを示したいと思います。

 


POSTMANとは


POSTMAN とは、 Postdot Technologies, Inc. が提供する、フリーミアムな WEB API テスト管理ツールです。
https://www.getpostman.com/

POSTMAN-Welcome

HTTP REST API を作成する時、 API をコールし、結果を表示するツールが欲しくなります。 POSTMAN は、 REST API のクライアントとして動作し、APIのコールと結果確認ができます。

Chrome 拡張、 Chrome アプリのほか、スタンドアロンアプリ(いわゆる exe 形式)の実行形態もあり、任意の実行形態を選択可能です。OSは、 Windows、 Linux や Mac もサポートしています。
スタンドアロンアプリもしっかり用意してくれているのは非常に助かります。別アプリへの依存は動作上の制限を伴うケースもあるからです。

注:ただし、スタンドアロンアプリの動作に必要なライブラリを導入する事が必要な場合があります。実際、CENTOS6やRHEL6で作動させる場合、GLIBCXX_3.4.15を別途導入する必要がありました。

 

なぜ、 WEB APIに テスト管理ツールが必要なのでしょうか。

 

通常、 HTTP REST APIは、「検索する商品コード」「検索する商品名」など、APIが要求するパラメータを与えて呼び出します。
APIをテストする場合、所定のテスト観点の元、これらのパラメータ設定を変えながら、想定される動作やデータの返却を順次確認していきます。

その際、パラメータ設定を都度書き換えながらテスト実行する方法があります。一度きりのテストなら、その方法でも良いですが、通常、テストは複数回繰り返して実行されるものです。その為、テスト観点とパラメータ設定値を記録し、再び同じテストを呼び出せるように管理する必要があります。パラメータの指定のバリエーションが多くなっていくほど、テストの管理がより重要になります。テスト管理ツールとしてPOSTMAN を利用すれば、その管理が容易になります。

 

POSTMAN の場合、APIテストに指定するパラメータは、Collection という単位で記録・管理する事ができます。指定するパラメータ毎に Collection を登録しておけば、いつでも・繰り返し API テストを呼び出す事ができます。

 


POSTMANを利用した API テストの実行


では早速、POSTMANを使って WEB API をテストしてみましょう。なお、テスト対象の WEB API は、パブリックに公開されているものを使います。事前に用意しておく必要はありません。

このアドレス から、環境に見合ったセットアップモジュールをダウンロードします。

POSTMANの導入については、特に難しい点はないと思いますので、詳しい手順は割愛します。(以降は、既に導入済みの前提となります)

 

今回は、 Swagger.io が公開するパブリックな HTTP REST API をテストしてみます。Swagger.ioはAPI 記述言語のデファクトスタンダードとなる Swaggerフォーマットに関するドキュメントなど、さまざまな情報を公開するページです。

 

REST API をテストするには、対象 API のメソッドやパラメータといった様式をPOSTMANに知らせる必要があります。ここでは、Swagger 形式のファイルのリンクをURLからインポートし POSTMAN に APIの様式を登録します。

 

まず、POSTMANの画面で Import ボタンを押下します。

swagger-import

インポート画面が表示されますので、下記のアドレスを指定します。ImportURLを選択し、下記のアドレスを記入します。

http://petstore.swagger.io/v2/swagger.json

swagger-url

Collection 欄に、「 Swagger Petstore 」というフォルダが追加表示されるはずです。

postman-collection

「 Swagger Petstore 」は、 ペットストアが公開する WEB API を模したデモ API です。Swagger形式ファイルのリンクアドレスをImport した事で、デモ API の仕様が POSTMAN に取り込まれ、各種メソッドの様式が解釈されます。Swagger PetstoreのCollectionは、API様式を解釈した上で表示されている状態となっています。

 

それでは、 POSTMAN から、 ペットストアのデモ API を呼び出してみます。

 


petstore のペットステータス一覧を取得


Collections から、 Store>Return pet inventories by status を選択します。

postman-itemclick

API の URI が選択されます。

postman-url

Send ボタンを押下します。

postman-url

結果が返されました。 Body 欄に、 ペットのステータス一覧が表示されたのが分かります。

 


該当するステータスのペット情報を取得


ステータス一覧の内容から、 cuty というステータスのペットがいる事が判りましたので、今度は、このステータスのペット情報を取得してみます。

 

コレクション欄から、 Finds Pets by status を選択します

postman-url

先ほどと同じように、 URI が呼び出されます。

postman-url2

URI の後ろに、 ?status={{status}} という記載があります。?以降の記載から、この REST API は、クエリストリングによりstatusというパラメータを引き渡せる事が判ります。

Params ボタンを押下して、パラメータ入力欄を表示します

postman-url2

パラメータの Status の入力欄 {{status}} を cuty という文字に置き換えて、 Send ボタンを押下します。

postman-url2

Body に gordon という名の亀の情報が表示されました。

postman-gordon

セットしたパラメータの指定を、次の実行でも呼び出せるようにする為に、 Save ボタンでテストを Save します。 Save したパラメータ指定は、 テストCollectionの一つとして POSTMAN に保存されます。

postman-gordon

↓↓「 Save ボタン押下後」↓↓

postman-gordon

 


呼び出し結果の自動チェック


API を呼び出して結果を閲覧する事ができました。実際のテストでは、結果が想定通り返ってきている事を自動でチェックしたい所です。そうすればテストが捗ります。
POSTMAN では、 API 実行結果をチェックするスクリプトが記述できます。

 

ここでは、 API のリクエストが Staus 200(OK) で返ってくる事、および API のレスポンスが 200 ミリ秒以内に返って来る事を、自動でチェックするスクリプトを設定してみます。

Tests タブを選択し、「 SNIPPETS 」欄から、「 Status code : Code is 200 」をクリックします。スクリプト記述欄にスクリプトが追加されます。

postman-status200

tests[“Status code is 200”] = responseCode.code === 200;

という記載が追加されたのが分かります。

さらにAPI レスポンスが 200ms (ミリ秒)未満である事をチェックする記述も追加します。
さきほどと同様に「 SNIPPETS 」欄から、「 Response time is less than 200ms 」をクリックし、下記のコードを追加します。

postman-res200ms

tests[“Response time is less than 200ms”] = responseTime < 200;

これらのチェックを走らせるには、 Send をクリックします。
Test(1/2) と書かれたタブをクリックすると、指定したチェック結果がどうだったかが分かります。

postman-tests-result

API は Status 200 で返ってきましたが、残念ながら 200ms までにはレスポンスを戻せなかったようです。

 

実際はもっと複雑なチェック処理を定義する必要があるかとおもいますが、今回はさわりだけです。 POSTMANのTestsスクリプトは、 API の結果チェックに必要なものは、あらかた出来てしまいますが、詳しい説明は紙幅の都合上割愛します。

 

API 呼び出しにおけるチェックをスクリプトによって自動化することで、テストが自動化できます。

POSTMANを活用したAPI-First開発では、まず初めに、期待する結果をスクリプトにて定義し、 スクリプトによるチェックをパスするよう、API を組み上げていくアプローチを取る事ができます。

このアプローチにより、API の品質と開発生産性が向上します。

 

「API-First開発」は「Test-First開発」であるとも言えるのです。

 


API テストの管理


POSTMAN は、 API のテストを、 Collection という単位で記録しておける事を先述しました。
Collection は、フォルダで分類し整理する事ができます。

(Collection のフォルダ)

postman-collection2

フォルダ名は、任意のもの(日本語も含む)が指定できますので、例えば「イレギュラーテスト」といったテスト観点の名前をフォルダ名にして、個別のチェックをフォルダ配下に配置していけば、テストをしっかり分類し管理する事ができます。

 

また、POSTMANのストレージに保存されたCollectionおよびテスト群は、 Import/Export によって、他の POSTMAN 環境に持ち出す事ができます。

Collection 欄を右クリックし、メニューから Export を選択すれば、Collectionに含まれたテストをエクスポートファイルとして出力できます。

postman-rightclick

 

この仕組みにより、開発時に行ったテストを、エクスポートファイルとしてお客さまに納入する事も可能となります。
お客さまの POSTMAN 環境に、 エクスポートファイルを Import してもらえれば、社内で実施したテストとまったく同じものを、お客さま環境から呼び出す事ができるようになります。

 


(まとめ) API テストの生産性は爆上げできたのか


駆け足とはなりましたが、 POSTMAN の概要について記載してきました。

 

今回は、お客さまに納入する WEB API の開発にあたり、 テスト管理ツールとしてPOSTMANを使いました。
POSTMAN上にAPIテストの結果チェックをスクリプトで記述し、テストをいつでも・繰り返し呼び出せるようにしました。Postmanの機能を活用しながらTest-FirstでAPIを開発し、APIテストの生産性を格段に向上させる事ができました。「API テストの生産性を爆上げする」ことに成功したと言えます。

 

また、 API テストをお客さまに納入し、お客さまご自身の環境でも、開発時に実施したテストと同じものをいつでも呼び出せるようにしました。これにより、テスト結果が社内・社外いずれも同様である事を保障する事ができるようになりました。

 

昨今、「API 経済圏」「API-First 開発」という言葉が注目を集めていますが、いざ API を開発するにあたって、具体的にこれまでの開発とどう違うのかを理解するうえで、API開発を取り巻く製品について知っておく事は有用です。

 

今回は API が既に存在する前提での記事となりました。しかしながら、メインフレームなどの様々なシステムが混在するなかで、「API-First開発」といってもそう簡単にはいかない、といったご意見も有るかと思います。

 

ユニリタでは、メインフレームを含む既存資産を活用しつつ、セキュアに API 化できる製品として「webMethods Integration Platform」を柱としたソリューションをご用意しております。他にも様々なソリューションで皆様の「API-First開発」をご支援させていただきますので、是非お気軽にユニリタにご相談ください。

 

既存システムをAPI化して、グローバルに展開する秘訣が満載。
最新のホワイトペーパーを是非ご覧ください。

おすすめ記事