Postmanは人気のChromeアプリケーションで、APIのテスト、ビルド、文書化に使える。Chromeウェブストアでは、4.6スターが付き、たくさんのレビューが投稿されており、100万人の開発者が使っていると思われる。
InfoQはPostmanのCEOであり、ファウンダーであるAbhinav Asthana氏にインタビューし、最新のリリースについて、読者がPostmanの理解を深められるよう、Postmanがどのように生まれたか、なぜAPI開発者に人気なのか、3.0で新しくなった点について、話を聞いた。
InfoQ: Postman誕生の物語について教えてください。Postmanはどのように進化してきたのでしょうか。
Abhinav Asthana: Postmanはシンプルなサイドプロジェクトとして始まりました。私は、2010年の始め、API開発をしていました。インターンとしてYahooで働いていたのです。一緒に働いていたのが、共同創業者のAnkitで、彼は、社員としてYahooに入社したばかりでした。フロントエンドの開発と、APIを通じてYahooの資産のデータを管理するサービスを開発していました。
APIのテストで使えるツールは使いにくいものでした。curlコマンドは恐ろしいもので、私たちとAPI開発者の間ではなんどもやりとりが生まれました。APIの変更は頻繁で、ミスはたくさん起きました。Yahooで働いた後、別の会社を創業し、そこでは、フロントエンドとバックエンドの両方の開発をしていました。チームが拡大し始めると、APIドキュメントの共有やテストなどで問題が起きました。問題が解決できる既存のツールを探し始めましたが、見つかりませんでした。
Postmanの最初のバージョンの主要な機能は、リクエストの履歴を辿り、再度リクエストできる機能でした。その後、すぐにPostman Collectionsが生まれました。その後、Postmanは口コミで評判になり、開発者コミュニティの支えもあって、成長しました。フィードバックは強力でした。Ankitと私はベーシック認証、OAuth 1.0などの認証の機能を追加しました。そして、Postmanの使われた方は私たちの知らないところで、さまざまに広がりました。ユーザからの反応に驚き、私たちはAPI開発に横たわる問題を深く探究し始め、その結果、Abhijitが私たちにジョインした2014年8月に会社を設立しました。
InfoQ: Postmanのビジョンを教えてください。
AA: Postmanは開発者やチームや会社がAPIライフサイクルのすべてのステップで素早く動けるようにします。APIの開発、利用では大量の反復が生まれます。テストは常に後回しになります。ドキュメントは、最後まで手をつけられません。チームが知らない問題もたくさんあります。
一定のプロセスを適用することで、この苦しみをある程度緩和することは可能でしたが、それでは不十分だと感じていました。開発者には優れたツールが必要です。開発者向けの製品は普通、単なるユーティリティであり、開発者のエクスペリエンスに注力していません。APIの数が爆発的に増えているため、APIの開発や利用では開発者のエクスペリエンスが重要になっていきます。
InfoQ: Postmanのさまざまなコンポーネントについて教えてください。
AA: Postmanのエコシステムには次のようなコンポーネントがあります。
- Postman Chromeアプリ: Postman Chromeアプリは、エコシステムの中核です。Chrome上のPostmanはリクエストの送信、レスポンスの分析、コレクション内でのリクエストの組成、テストなどの機能を提供します。ほとんどの開発者にとって、このアプリがスタートポイントでしょう。
- Postman Collections: Postman Collectionsはリクエストのグループを記述するメタデータのフォーマットです。APIのドキュメントに使われます。CollectionsはJSONファイルでダウンロードでき、どこでも利用できます。
- Newman: NewmanはPostmanのコマンドラインツールで、node.jsを使っています。Postmanの外でCollectionsを受け取り、コマンドラインで実行できます。Newmanは全てのプラットフォームで実行できます。Newmanはビルドツールに統合したり、単に定期的にAPIを呼び出したりするのにも使えます。コマンドラインにしたことで、ほとんどの外部システムと統合できるようにしました。
- InterceptorとProxy: コードをいじらずにプロダクション間ん今日のリクエストをキャプチャするのを支援するふたつのツールがあります。InterceptorはChromeからのリクエストをPostmanの履歴に流し、分析したり、合成したりできます。Postman Proxyはディスクトップアプリやモバイルアプリで同じことができます。私たちはこのふたつのツールの改善を続けています。Interceptorには他にも使い道があります。PostmanとChromeの間をブリッジし、PostmanがChromeのcookieを使えるようにします。
- Postman Sync: 私たちの最新の製品で、プライベートベータで開発を続けていました。Postman Syncを使うとチームで協力してAPI開発を進められます。Collectionsをチームで共有し、リアルタイムで変更を共有します。Postman内部は自動的にバックアップされ、適切なアクセス制御をした上で、チームで共有できます。Postman Syncを使えば、Postmanや他のツールを使ってチームはAPI開発で密接に協力できます。
PostmanのツールはAPI開発のさまざまな側面で起こる摩擦をスムーズにするのが目的です。Collectionsが共通の要素であり、Postman Syncは文字通り、チームの全員の足並みが揃うようにするサービスです。
InfoQ: Postmanのバージョン3のベーダが発表されました。バージョン2の発表から３カ月後です。大きな変更は何でしょうか。いつ頃正式なリリースになるのでしょうか。
AA:バージョン2は個人開発者向けにPostman Syncをリリースしたことを示したものでした。バージョン3は、開発者のエクスペリエンスを再考し、機能追加を行っています。
バージョン3の特筆するべき機能は以下の通り。
- 新しいデザイン言語を使った新しいユーザインターフェイス
- Postman内でドキュメントをみるためのCollection Browser
- 複数のリクエストをみるためのタブ
- コード生成
- 検索の改善
- Postman Syncが誰でも無料で使える
バージョン3はいくつかの素晴らしい機能のベースになるでしょう。今週には利用できるようになります。
InfoQ: Postmanコミュニティでのあなたの経験から言って、現在の主要なAPI開発のワークフローはどのようなものでしょうか。どのように進化しているでしょう。あなたはどのようなワークフローを推奨しますか。
AA: ワークフローはチームによってさまざまです。APIの幅広さを考慮すると、全般的に適用できるワークフローを見つかるのは難しいです。API開発にはさまざまな変数があります。例えば、次のようなものです。
- APIの機能性 - APIの目的、最重要な機能は何か、利用頻度
- APIのサイズ - エンドポイントの数、APIの大きさ
- インフラ - 企業で内部システムがどのように構成されているか、既存のアーキテクチャや手法はあるか
- APIの利用 - バックエンドの開発者だけか、それともフロントエンドの開発者もいるのか、品質保証の開発者は別にいるのか。公開APIなのか、内部APIなのか
開発者はすべての変数におおよそ適合するようなワークフローを選びます。しかし、これは、APIが進化するに従って問題を引き起こします。例えば、内部の開発者しか使わないからドキュメントを作成しない、という選択をするかもしれません。
もっとも一般的なワークフローでは、APIはコードの中で生まれます。まず、利用者に提供されて、それからドキュメントやテストが書かれます。API設計ツールはt具変われる場合もあります。
特定のワークフローを推奨することはありませんが、私たちのツールによって、開発者が、テストされ、ドキュメントが作られ、しっかりと動作する良いAPIを開発するのを支援したいと思っています。そうすることで、私たちはさまざまなチームとつながり、Postmanを使いたいように使ってもらえるようになります。T
InfoQ: 6月の始め、Postman Collectionsのフォーマットのバージョン2を発表しましたね。何が変わったのでしょうか。API開発者にとってなぜ大事なのでしょうか。
AA:
Postmanの現在のCollectionフォーマットは偶然に発見されたものです。このフォーマットはPostmanのリクエストのグループを保存するための内部フォーマットです。もともとは、Collectionsを使う開発者が増えるにつれ進化してきたものです。
しかし、Postmanの新しい機能を開発しながら、私たちはこの進化の仕方が最適なものではないということに気づきました。一歩引いてCollectionsの周りのAPIワークフローの全体を俯瞰しました。そして、開発者のPostmanのユースケースと私たちが実現できるユースケースを考えました。それらのことをすべて考慮して、バージョン2のフォーマットのドラフトを発表しました。まだ、積極的に開発していますし、コミュニティからのフィードバックを求めています。
Postman CollectionsがAPIエコノミーの鍵になると信じていますし、開発者のための強固な基盤にしたいと考えています。
InfoQ:Postman Collectionsのフォーマットは他のAPI記述言語と比べて、どうでしょうか。API Blueprint、RAML、Swaggerというような言語です。
AA: API記述言語はPostman Collectionsとは全く違いますが、重複する部分もあります。Postman Collectionは既存のAPIがあれば、真実を語る資料となります。また、APIコールの流れを単一のユースケースシナリオにマッピングするのにも使えます。Collectionsはプログラムそのものとしても使えます。Collection RunnerとNewmanを使ってユースケースを実行すればいいのです。
Collectionの使い方には制限はありません。私たちの目的は、Collectionsを使って開発者が先にAPIのドキュメントを作らずに、APIワークフローの問題を解決するを支援することです。このCollectionsの自由な性質は、開発者の生産性改善に寄与します。
また、もうひとつの大きな違いとして、Postman Collectionsには、JavaScriptのコードを含むことができるという点です。Collectionsの内部のAPIのエンドポイントは、テストコードが内部に書かれていたら、それ自体でテストできます。これによって開発者は大きな力を得ます。また、Collectionsを別のフォーマットと変換できるようにしたいと思っています。すでに、ほとんどの人気のフォーマット用のインポートの仕組みを用意していますが、さらにフォーマットを追加したいと思っています。
InfoQ: Kin Laneのブログ記事をベースにしたHARフォーマット(HTTPアーカイブ)に注目が集まっています。Postman CollectionsはAPIのバリューチェーン全体にどのようにフィットしていると思いますか。
AA: HARについては調査をしました。Chromeを使うとHARフォーマットでリクエストをダウンロードできます。HARのデータをインポートできる機能を求めているユーザもいます。ブラウザベースの製品の場合、データはすでにHAR形式で使えるので、この機能は合理的です。HARを生成している開発者を見たことはありません。
Postman Collectionsを使うとリクエストとレスポンスを保存できます。バックエンドで自動的にこの情報を収集しているユーザもいます。そして、そのデータをPostmanに戻してデバッグに使うのです。これは面白い使い方です。実際のプロダクションのデータと設計の仕様を合わせて、何がうまくいって何がうまくいかないのかを検討するという方法の可能性にはとてもワクワクしています。
InfoQ: Postmanを使うと、ログインの情報やトークンなど重要なデータを変更できてしまいます。APIの開発者はセキュリティについて関心を払うべきでしょうか。製品の視点からはセキュリティを考慮していますか。
AA: もちろんです。APIのセキュリティは開発者にとって第一優先であるべきです。APIは大きな力を振り回します。もし、セキュリティを考慮していないなら、恐ろしい結果になりかねません。APIのメタデータやサンプルの呼び出しを共有すると、うっかりトークンやパスワードを公開することになってしまうかもしれません。
私たちはこの問題にPostman内部で対処しています。利用環境とグローバル変数を通じて重要な情報が分離されるようにしています。API呼び出しで重要なデータがあるなら、そのデータ用の変数を作成できます。その変数の値は、環境/グローバルに保存され、Postmanはリクエストのときにその変数を代用します。このようにすることで、開発者は望ましくないデータを共有することなく、Collectionを共有できます。
Sync向けには、サーバサイドの環境変数を暗号化しています。また、パスフレーズを使ったクライアント側の暗号化もサポートする予定です。もちろん、サーバとPostmanアプリ間のすべての通信は、セキュアなチャンネルになっています。
InfoQ: PostmanはChrome拡張として始まり、今はChromeアプリになっています。なぜ、このように変化したのでしょうか。Chrome向けの開発環境の進化についてはどう考えていますか。
AA: Postmanは今となってはレガシーになってしまったChromeアプリプラットフォームを使ったブラウザ内アプリとして生まれました。Chromeアプリのエクスペリエンスをネイティブアプリに近づけるため、Googleはサンドボックスを強化しより多くのAPIを追加した、新しいChromeアプリプラットフォームを作りました。これは、Postmanにとって、とても良いものであり、苦労しなくてもテストスイートを開発できるようになりました。また、私たちはブラウザ内メッセージングシステムのためにブラザへのリンクは維持しています。
私たちは、Chromeが既存のプラットフォームを破棄するという決定をする場合に備えるためにこの変更をしたかったのです。私はこの決定は良いものだったと思います。その少しあと、Chromeはユーザがレガシーなアプリのアップロードしないようにしたからです。私たちはレガシーなアプリのバグ修正や更新をまだやっています。しかし、すべてのユーザを完全に新しいアプリへ移行させるのがゴールです。
ChromeアプリのエコシステムはPostmanの重要な成長ドライバーです。ひとつの言語を使って、オペレーティングシステムを超えてユーザにリーチできたのです。また、ブラウザと強く結びつき、Chrome DevToolsにアクセスすることで、Postmanの機能を補完することもできました。Chromeアプリがネイティブアプリに比肩するには、もう少しAPIが必要です。新しいユーザ向けのエクスペリエンスとウィンドウ管理には課題があります。しかし、プラットフォームは素早く進化していくだろうと楽観視しています。
InfoQ: 将来、他のブラウザにもPostmanを展開する計画はありますか。ディスクトップ環境はどうでしょうか。
AA: それらの選択肢は真剣に検討しています。いくつか素晴らしいアイディアもあり、ネイティブのディスクトップ環境があれば、このアイディアたちをより良いかたちで実現できます。もう少ししたら、発表できると思います。
免責: この記事の著者はウェブAPIプラットフォームプロバイダーであり、Postmanを含む複数のテストツールをサポートしているRestletで働いています。