JP2016170548A - 情報処理システム、情報処理装置および情報処理プログラム - Google Patents

Abstract

【課題】依存関係がある複数のＡＰＩの動作確認を容易とする。【解決手段】動作確認ツールは以下のように動作する。まず、プログラムに実装されるＡＰＩのリクエスト及びレスポンスを定義するスキーマ情報を格納する。ＡＰＩ及びその実行順序をユーザ操作に応じて選択しＳ１００、選択されたＡＰＩ毎にスキーマ情報を取得するＳ１０３。選択されたＡＰＩに対するリクエストを設定するための設定部を、取得されたスキーマ情報に基づき生成する。次に、設定部で設定されたリクエストを用いて、選択されたＡＰＩを順序に従い実行させる。上述の設定部を生成する際、取得されたスキーマ情報に定義されるリクエストに、選択されたＡＰＩのうちリクエストが定義されるＡＰＩよりも順序が前のＡＰＩのレスポンスが含まれている場合には、レスポンスをリクエストとして設定部に設定する。こうしてＡＰＩ間に依存関係がある場合でもその動作確認が容易に行える。【選択図】図１３

Description

本発明は、情報処理システム、情報処理装置および情報処理プログラムに関する。

一般的に、例えばＯＳ(Operating System)やＷｅｂサービスといったプログラムを利用する際には、それぞれのプログラムに適合したＡＰＩ(Application Programming Interface)に従いパラメータの入力などを行う。例えば、Ｗｅｂサービスの提供者は、提供するＷｅｂサービスに適合したＡＰＩおよび当該ＡＰＩを実装するためのプログラムを用意する。このＷｅｂサービスの利用者は、このプログラムに対して必要なパラメータを入力する。プログラムは、ＡＰＩに従い、入力されたパラメータに基づき例えば所定のデータ構造を生成してＷｅｂサービスに渡す。

従来から、ＡＰＩの開発者が、当該ＡＰＩを利用する利用者のために、当該ＡＰＩによる動作を確認するための動作確認ツールを提供することが、一般的に行われている。動作確認ツールは、例えば、必要なパラメータを入力することで当該ＡＰＩによるリクエストを作成し、当該リクエストに対するレスポンスを返す。また、このような動作確認ツールにおいて、パラメータの入力を行うためのＵＩ(User Interface)を、ＡＰＩに基づき自動で生成し、入力値から自動でリクエストを生成するようにしたものが知られている。

例えば、特許文献１は、ＷｅｂサービスのためのＷｅｂＡＰＩライブラリの定義情報ファイルから、入力ボックスを表示するコードを生成し、生成された入力ボックスに入力された情報に基づきＷｅｂＡＰＩ関数の動作確認を行う技術が開示されている。この特許文献１の技術を用いることで、ＷｅｂＡＰＩライブラリの開発者および利用者の双方に対し、当該ＷｅｂＡＰＩライブラリに含まれるＷｅｂＡＰＩ関数の動作確認の利便性を向上させることができる。

しかしながら、従来技術による動作確認ツールは、単体のＡＰＩによる動作を確認するリクエストの自動作成は可能であったが、複数のＡＰＩ間に依存関係が存在する場合には、ＵＩやリクエストの自動作成が困難であるという問題点があった。この問題は、上述した特許文献１でも解決できていない。

本発明は、上記に鑑みてなされたものであって、依存関係がある複数のＡＰＩによる動作確認を容易とすることを目的とする。

上述した課題を解決するために、本発明は、プログラムに実装されるプログラムインタフェースの少なくともリクエストおよびレスポンスを定義するスキーマ情報を格納する格納部と、プログラムインタフェースをユーザ操作に応じて選択し、選択されたプログラムインタフェースの順序を指定する選択部と、選択されたプログラムインタフェース毎にスキーマ情報を取得する取得部と、選択されたプログラムインタフェースに対するリクエストを設定するための設定部を、取得部により取得されたスキーマ情報に基づき生成する生成部と、選択されたプログラムインタフェースが実装されるプログラムを、選択されたプログラムインタフェースに設定部で設定されたリクエストを用いて、順序に従い実行させる実行制御部とを備え、生成部は、取得部で取得されたスキーマ情報に定義されるリクエストに、選択されたプログラムインタフェースのうちリクエストが定義されるプログラムインタフェースよりも順序が前のプログラムインタフェースのレスポンスが含まれている場合に、レスポンスをリクエストとして設定部に設定する。

本発明によれば、依存関係がある複数のＡＰＩによる動作確認が容易になるという効果を奏する。

図１は、第１の実施形態に係る情報処理システムの一例の構成を示す図である。 図２は、利用者ＰＣからＷｅｂアプリに対してＡＰＩに従ったリクエストを送信した場合のＷｅｂアプリの動作を概念的に示す図である。 図３は、第１の実施形態に係るＷｅｂサーバのハードウェアの一例の構成を示すブロック図である。 図４は、第１の実施形態に適用可能な利用者ＰＣのハードウェアの一例の構成を示すブロック図である。 図５は、第１の実施形態に係るＷｅｂサーバの機能を説明するための一例の機能ブロック図である。 図６は、ＡＰＩについて概略的に説明するための図である。 図７は、既存技術による動作確認ツールによる動作の例を示す図である。 図８は、第１の実施形態に係る、ＡＰＩ機能を定義するためのスキーマ情報の一例を示す図である。 図９は、第１の実施形態に係るスキーマ定義の例を示す図である。 図１０は、第１の実施形態に係るスキーマ定義の例を示す図である。 図１１は、第１の実施形態に係るスキーマ定義の例を示す図である。 図１２は、第１の実施形態に係るスキーマ定義の例を概略的に示す図である。 図１３は、第１の実施形態に係る動作確認ツールの動作を説明するための一例のフローチャートである。 図１４は、第１の実施形態に係るＡＰＩ選択画面の例を示す図である。 図１５は、第１の実施形態に係る動作確認画面の例を示す図である。 図１６は、第１の実施形態に係る動作確認ツールによるＡＰＩ機能の動作確認処理を示す一例のフローチャートである。 図１７は、第１の実施形態に係る、リクエスト情報およびレスポンス情報の表示例を示す図である。 図１８は、第２の実施形態に係る動作確認画面の例を示す図である。 図１９は、第２の実施形態に係る動作確認ツールの動作を説明するための一例のフローチャートである。 図２０は、第２の実施形態の変形例に係る動作確認画面の例を示す図である。 図２１は、第３の実施形態に係るＡＰＩ選択画面の例を示す図である。 図２２は、第４の実施形態に係るＡＰＩ選択画面の例を示す図である。

以下に添付図面を参照して、情報処理システム、情報処理装置および情報処理プログラムの実施形態を詳細に説明する。

（第１の実施形態）
図１は、第１の実施形態に係る情報処理システムの一例の構成を示す。図１において、情報処理システム１は、Ｗｅｂアプリ１１が搭載されるＷｅｂサーバ１０を含み、Ｗｅｂサーバ１０がインターネットなどのネットワーク４０を介してＡＰＩ群２０、提供者用ＰＣ（パーソナルコンピュータ）３０および利用者ＰＣ３１と通信可能に接続される。

Ｗｅｂアプリ１１は、Ｗｅｂサーバ１０が備えるＣＰＵ(Central Processing Unit)上で動作する１以上のアプリケーションプログラムであって、例えば第１の実施形態に係る動作確認ツールを含む。ＡＰＩ群２０は、Ｗｅｂアプリ１１が利用するＡＰＩ(Application Programming Interface)のスキーマを定義するスキーマ情報や、ＡＰＩにより呼び出される関数などのライブラリを含むもので、実体は、例えばネットワーク４０に通信可能に接続されるストレージ装置である。これに限らず、ＡＰＩ群２０をＷｅｂサーバ１０内に設けてもよい。

例えば、Ｗｅｂアプリ１１は、所定の機能のＡＰＩが実装され、動作に応じて実装されたＡＰＩに従ったリクエストを生成する。Ｗｅｂサーバ１０は、Ｗｅｂアプリ１１により生成されたリクエストを、ネットワーク４０を介してＡＰＩ群２０に送信する。ＡＰＩ群２０は、送信されたリクエストに従い例えば所定の関数を呼び出して、この関数により、リクエストに応じたレスポンスを生成してＷｅｂサーバ１０に送信する。

提供者ＰＣ３０および利用者ＰＣ３１は、それぞれ一般的なコンピュータを用いることができる。提供者ＰＣ３０は、例えば、Ｗｅｂアプリ１１に実装されるＡＰＩの開発を行いＡＰＩ提供者により使用されるコンピュータである。ＡＰＩ提供者は、提供者ＰＣ３０を用いてＡＰＩを開発し、ＡＰＩのスキーマ定義を示すスキーマ情報を例えばＡＰＩ群２０に格納する。また、提供者ＰＣ３０は、開発したＡＰＩをＷｅｂアプリ１１に実装し、このＡＰＩをＷｅｂアプリ１１の利用者に提供する。

利用者ＰＣ３１は、例えば、上述した提供者により開発されたＡＰＩが実装されたＷｅｂアプリ１１を用いてエンドユーザなどに対するサービスを提供する、ＡＰＩ利用者により使用されるコンピュータである。このとき、ＡＰＩ利用者は、利用者ＰＣ３１からＷｅｂサーバ１０上のＷｅｂアプリ１１としての動作確認ツールを起動して、利用するＡＰＩによる動作を確認することができる。

なお、図１では、Ｗｅｂサーバ１０が１台のコンピュータにより構成されるように示しているが、これはこの例に限定されず、Ｗｅｂサーバ１０を互いに通信可能に接続される複数台のコンピュータにより構成してもよい。また、Ｗｅｂサーバ１０を、互いにネットワークで接続される複数のコンピュータを含み、外部からは、その内部が隠蔽されたブラックボックスとして入出力のみが示されるネットワーク・グループであるネットワーククラウドを用いて構成してもよい。

図２は、利用者ＰＣ３１からＷｅｂアプリ１１に対してＡＰＩに従ったリクエストを送信した場合のＷｅｂアプリ１１の動作を概念的に示す。ここで、Ｗｅｂアプリ１１は、それぞれ対応する機能を順次実行するための、複数のＡＰＩ＃１、ＡＰＩ＃２、…、ＡＰＩ＃ｎが実装されているものとする。利用者ＰＣ３１は、Ｗｅｂアプリ１１に対する変数の値を入力してＷｅｂサーバ１０に送信した後、Ｗｅｂアプリ１１の実行の指示をＷｅｂサーバ１０に送信する。Ｗｅｂサーバ１０は、利用者ＰＣ３１から送信された変数値と実行指示とを受信し、Ｗｅｂアプリ１１に渡す。

Ｗｅｂアプリ１１は、実行指示に応じて起動され、渡れた変数値に基づき、最初の機能を実行するＡＰＩ＃１に対するリクエストを生成する。このリクエストは、ＡＰＩ群２０に渡される。ＡＰＩ群２０において、ＡＰＩ＃１のリクエストに対してレスポンスが生成される。例えば、ＡＰＩ群２０において、ＡＰＩ＃１のリクエストに応じて対応する関数が呼び出され、呼び出された関数に利用者ＰＣ３１から受信された変数値が渡される。この関数は、渡された変数値に応じた値をレスポンスとして出力する。ＡＰＩ＃１によるリクエストに対するレスポンスは、Ｗｅｂアプリ１１に返される。

Ｗｅｂアプリ１１は、このＡＰＩ＃１のレスポンスに応じて、次のＡＰＩ＃２に対するリクエストを生成してＡＰＩ群２０に渡す。ＡＰＩ群２０からこのＡＰＩ＃２のリクエストに応じたレスポンスがＷｅｂアプリ１１に返される。Ｗｅｂアプリ１１は、このレスポンスに応じて、次のＡＰＩ＃３に対するリクエストを生成してＡＰＩ群２０に渡す。この、Ｗｅｂサーバ１１とＡＰＩ群２０との間でのリクエストとレスポンスとのやりとりは、Ｗｅｂアプリ１１が最後のＡＰＩ＃ｎによるレスポンスをＡＰＩ群２０から受け取るまで繰り返される。

Ｗｅｂアプリ１１は、ＡＰＩ群２０から最後のＡＰＩ＃ｎのリクエストに応じたレスポンスを受け取り、受け取ったレスポンスを利用者ＰＣ３１に送信する。これにより、利用者ＰＣ３１は、最初に送信したリクエストに応じた、各ＡＰＩ＃１、ＡＰＩ＃２、…、ＡＰＩ＃ｎによるレスポンスを纏めて受け取ることができる。

これは、Ｗｅｂアプリ１１を動作確認ツールとしても同様である。詳細は後述するが、動作確認ツールにおいては、Ｗｅｂアプリ１１とＡＰＩ群２０との間でやりとりされた各リクエストおよび各レスポンスを纏めて利用者ＰＣ３１に送信する。したがって、ＡＰＩ利用者は、利用者ＰＣ３１に対して変数値を入力し実行を指示するだけで、Ｗｅｂアプリ１１上で生成される各リクエストと、各リクエストに応じてＷｅｂアプリ１１が取得する各レスポンスとを纏めて受け取ることができる。

（第１の実施形態に適用可能な構成）
次に、第１の実施形態に適用可能な構成について、より具体的に説明する。図３は、第１の実施形態に係るＷｅｂサーバ１０のハードウェアの一例の構成を示す。図３において、Ｗｅｂサーバ１０は、ＣＰＵ１０１と、ＲＯＭ(Read Only Memory)１０２と、ＲＡＭ(Random Access Memory)１０３と、ストレージ１０４と、通信Ｉ／Ｆ１０５とを含み、これら各部がバス１００により互いに通信可能に接続される。

ＣＰＵ１００は、ＲＯＭ１０２およびストレージ１０４に記憶されるプログラムに従い、ＲＡＭ１０３をワークメモリとして用いて、このＷｅｂサーバ１０の全体の動作を制御する。

ストレージ１０４は、データを不揮発に記憶することが可能な記憶媒体であって、例えばハードディスクドライブである。これに限らず、ストレージ１０４として、フラッシュメモリなどの不揮発性の半導体メモリを用いてもよい。ストレージ１０４は、ＣＰＵ１０１が実行するためのプログラムや各種データが格納される。また、上述したＡＰＩ群２０を、このストレージ１０４上の記憶領域を用いて構成することができる。

通信Ｉ／Ｆ１０５は、ＣＰＵ１０１の制御に従いネットワーク４０を介した通信を行う。

なお、図３では、ストレージ１０４が１のハードウェアから構成されるように示しているが、これはこの例に限定されず、例えば複数のストレージ装置を１つのストレージ１０４として統合的に管理するようにしてもよい。また、図３では、Ｗｅｂサーバ１０が１のハードウェアから構成されるように示しているが、これはこの例に限定されず、Ｗｅｂサーバ１０を、同等の構成を有する複数のサーバ装置を統合的に制御することで構成してもよい。

図４は、第１の実施形態に適用可能な利用者ＰＣ３１のハードウェアの一例の構成を示す。図４において、提供者ＰＣ３０は、ＣＰＵ１２１と、ＲＯＭ１２２と、ＲＡＭ１２３と、表示信号生成部１２４と、ストレージ１２６と、データＩ／Ｆ１２７と、入力デバイス１２８と、通信Ｉ／Ｆ１２９とを含み、これら各部がバス１２０により互いに通信可能に接続されている。

ストレージ１２６は、データを不揮発に記憶することが可能な記憶媒体であって、例えばハードディスクドライブが用いられる。これに限らず、ストレージ１２６として、フラッシュメモリなどの不揮発性の半導体メモリを用いてもよい。ストレージ１２６は、ＣＰＵ１２１が実行するためのプログラムや各種データが格納される。

ＣＰＵ１２１は、ＲＯＭ１２２およびストレージ１２６に記憶されるプログラムに従い、ＲＡＭ１２３をワークメモリとして用いて、この利用者ＰＣ３１の全体の動作を制御する。

表示信号生成部１２４は、ＣＰＵ１２１により生成された表示制御命令に従い、表示装置１２５による表示を制御するための表示制御信号に変換して出力する。表示装置１２５は、表示信号生成部１２４から供給された表示制御信号に応じた表示を行う。

データＩ／Ｆ１２７は、外部機器との間でデータの入出力を行う。データＩ／Ｆ１２７としては、例えば、ＵＳＢ(Universal Serial Bus)やＢｌｕｅｔｏｏｔｈ（登録商標）といったインタフェースを適用することができる。通信Ｉ／Ｆ１２９は、ＣＰＵ１２１の命令に従いネットワーク４０を介した通信を制御する。入力デバイス１２８は、例えばマウスなどのポインティングデバイスや、キーボードを含み、ユーザ操作を受け付ける。ユーザは、例えば表示装置１２５に対する表示に応じて入力デバイス１２８を操作することで、利用者ＰＣ３１に対して指示を出すことができる。

図５は、第１の実施形態に係るＷｅｂサーバ１０の機能を説明するための一例の機能ブロック図である。図５において、Ｗｅｂサーバ１０は、１以上のプログラムにより構成されるアプリケーションプログラムであるＷｅｂアプリ１１を含む。また、Ｗｅｂサーバ１０は、複数のＷｅｂアプリ１１を含むことができる。以下では、Ｗｅｂアプリ１１が上述した動作確認ツールであるものとして説明する。Ｗｅｂアプリ１１は、格納部１０００と、操作部１００１と、選択部１００２と、取得部１００３と、生成部１００４と、実行制御部１００５と、表示情報生成部１００６とを含む。

格納部１０００は、ストレージ１０４やＡＰＩ群２０に対して情報を格納する。格納部１０００は、例えば、Ｗｅｂアプリ１１に実装されるＡＰＩの少なくともリクエストおよびレスポンスを定義するスキーマを示すスキーマ情報を、ＡＰＩ群２０に格納する。操作部１００１は、ユーザ操作に応じた指示を受け付ける。操作部１００１は、外部の機器、例えば提供者ＰＣ３０や利用者ＰＣ３１などに対するユーザ操作をネットワーク４０を介して受け付ける。

選択部１００２は、操作部１００１に受け付けられたユーザ操作に応じて、ＡＰＩ機能を選択する。また、選択部１００２は、選択されたＡＰＩ機能の順序を指定する。取得部１００３は、選択部１００２で選択されたＡＰＩ機能のスキーマ情報を、例えばストレージ１０４やＡＰＩ群２０から取得する。生成部１００４は、選択部１００２により選択されたＡＰＩ機能に対応するスキーマ情報に基づき、リクエストを設定するための設定部を生成する。実行制御部１００５は、Ｗｅｂアプリ１１（動作確認ツール）の全体の動作を制御する。また、実行制御部１００５は、選択部１００２で選択されたＡＰＩ機能が実装されるプログラムを、設定部で設定されたリクエストを用いて、指定された順序に従い実行させる。

表示情報生成部１００６は、表示を行うための表示情報を生成する。例えば、表示情報生成部１００６は、生成部１００４により生成された設定部を表示するための表示情報を生成する。また例えば、表示情報生成部１００６は、実行制御部１００５による実行結果を表示するための表示情報を生成する。表示情報生成部１００６で生成された表示情報は、例えばネットワーク４０を介して提供者ＰＣ３０や利用者ＰＣ３１に送信される。

これら格納部１０００、操作部１００１、選択部１００２、取得部１００３、生成部１００４、実行制御部１００５および表示情報生成部１００６は、例えばストレージ１０４上に記憶され、ＣＰＵ１０１上で動作する情報処理プログラムにより実現される。この情報処理プログラムは、インストール可能な形式また実行可能な形式のファイルでＣＤ(Compact Disk)、フレキシブルディスク（ＦＤ）、ＤＶＤ(Digital Versatile Disk)などのコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、第１の実施形態のＷｅｂサーバ１０で実行される情報処理プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、当該ネットワークを介してダウンロードさせることにより提供するように構成してもよい。また、第１の実施形態のＷｅｂサーバ１０で実行されるプログラムをインターネットなどのネットワークを経由して提供または配布するように構成してもよい。さらに、第１の実施形態の情報処理プログラムを、ＲＯＭ１０２などに予め組み込んで提供するように構成してもよい。

第１の実施形態のＷｅｂサーバ１０で実行される情報処理プログラムは、上述した各部（格納部１０００、操作部１００１、選択部１００２、取得部１００３、生成部１００４、実行制御部１００５および表示情報生成部１００６）を含むモジュール構成となっている。実際のハードウェアとしては、ＣＰＵ１０１がストレージ１０４やＲＯＭ１０２などの記憶媒体から当該情報処理プログラムを読み出して実行することにより、上述した各部がＲＡＭ１０３などの主記憶装置上にロードされ、格納部１０００、操作部１００１、選択部１００２、取得部１００３、生成部１００４、実行制御部１００５および表示情報生成部１００６が主記憶装置上に生成されるようになっている。

（既存技術について）
次に、既存技術について概略的に説明する。図６は、ＡＰＩについて概略的に説明するための図である。図６において、リクエスト２１０がプログラム２００に入力される。このとき、リクエスト２１０は、プログラム２００に実装されるＡＰＩを実現するＡＰＩ機能２０１により規定される例えばデータ構造のデータ２１１に変換されて、プログラム２００に渡される。すなわち、ＡＰＩ機能２０１は、プログラム２００に対するインタフェースとして機能する。プログラム２００は、データ２１１に対して処理を実行し、処理結果のデータ２１２を生成する。このデータ２１２は、ＡＰＩにより規定されるデータ構造のレスポンス２１３に変換されて出力される。

ＡＰＩ機能２０１を利用する利用者が、ＡＰＩ機能２０１による動作を確認したい場合がある。図６の例の場合、例えばプログラム２００をＡＰＩ機能２０１の動作を確認する動作確認ツールとする。動作確認ツールは、ＡＰＩ機能２０１に定義されるスキーマ情報に基づき、リクエスト２１０を入力するリクエスト入力部が設けられたＵＩ(User Interface)を自動的に生成することができるようになっている。動作確認ツールは、例えば、利用者がリクエスト入力部に対してリクエスト２１０を入力すると、入力されたリクエスト２１０に対応して返されたレスポンス２１３が表示されるようになっている。

実際には、ＡＰＩ機能２０１は、複数が組み合わせれて使用されることが多い。図７は、この場合の既存技術による動作確認ツールによる動作の例を示す。ここでは、サービス登録に対して値keyおよび値valueを生成する一連の処理を例にとって説明する。この処理では、サービス登録、ログインおよび値key、value登録の３段階に処理が実行され、それぞれ異なるＡＰＩ機能２０１が適用される。図７の例では、サービス登録処理に適用される第１のＡＰＩ機能２０１と、ログイン処理に適用される第２のＡＰＩ機能２０１と、値key、value登録の第３のＡＰＩ機能２０１とが組み合わせて使用される場合の動作例が示されている。

動作確認ツールは、先ず、第１のＡＰＩ機能２０１のスキーマ情報に従い、第１の確認画面３４０を生成し、利用者に提示する。図７の例では、第１の確認画面３４０は、第１のＡＰＩ機能２０１に対するリクエスト２１０（パスワードとする）を入力するためのリクエスト入力部３４００が設けられる。動作確認ツールは、利用者によりリクエスト入力部３４００にリクエスト２１０が入力され実行が指示されると、予め設定された、第１のＡＰＩ機能２０１によるレスポンス２１３（ＩＤとする）をレスポンス表示部３４０１に表示させる。

次に、動作確認ツールは、第２のＡＰＩ機能２０１のスキーマ情報に従い、さらに第２の確認画面３４１を生成し、利用者に提示する。図７の例では、第２のＡＰＩ機能２０１は、リクエスト２１０として、第１のＡＰＩ機能２０１に対するリクエスト２１０であるパスワードと、第１のＡＰＩ機能２０１のレスポンス２１３であるＩＤを要求する。利用者は、第１の確認画面３４０においてリクエスト入力部３４００に入力した値（パスワード）と、レスポンス表示部３４０１に表示された値（ＩＤ）とを、第２の確認画面３４１に設けられるリクエスト入力部３４１０にそれぞれ入力し、実行を指示する。動作確認ツールは、この操作に応じて、予め設定された、第２のＡＰＩ機能２０１によるレスポンス２１３（クッキーとする）をレスポンス表示部３４１１に表示させる。

さらに、動作確認ツールは、第３のＡＰＩ機能２０１のスキーマ情報に従い、さらに第３の確認画面３４２を生成し、利用者に提示する。図７の例では、第３のＡＰＩ機能２０１は、リクエスト２１０として、第２のＡＰＩ機能２０１に対するリクエスト２１０であるＩＤと、第２のＡＰＩ機能２０１のレスポンス２１３であるクッキーと、値keyおよび値valueとを要求する。利用者は、第２の確認画面３４１においてリクエスト入力部３４１０に入力した値（ＩＤ）と、レスポンス表示部３４１１に表示された値（クッキー）とを、リクエスト入力部３４２０にそれぞれ入力し、実行を指示する。なお、値keyおよび値valueは、予め設定されているものとする。動作確認ツールは、この操作に応じて、予め設定された、第３のＡＰＩ機能２０１によるレスポンス２１３である値keyおよび値valueをレスポンス表示部３４２１に表示させる。

既存技術では、スキーマ情報には、リクエストのスキーマは定義されるが、レスポンスのスキーマは定義されないため、リクエストに対してどのようなレスポンスが返ってくるか、知ることが困難であった。したがって、動作確認ツールは、各ＡＰＩ機能２０１に対応する第１〜第３の確認画面３４０〜３４２をそれぞれ利用者に提示し、利用者は、第２の確認画面３４１および第３の確認画面３４２に、それぞれ直前の確認画面に表示される値を入力する必要があった。この場合、使用されるＡＰＩ機能２０１の数が多くなると、利用者の負担が増加すると共に、入力ミスなども発生し易くなり、作業効率が低くなるおそれがある。

そのため、第１の実施形態では、スキーマ情報にレスポンスのスキーマをさらに定義し、動作確認ツールがリクエストに対して直前のレスポンスを反映できるようにした。

（第１の実施形態に係るスキーマ情報の概略）
図８〜図１１を用いて、第１の実施形態に係る、ＡＰＩを定義するための定義情報について説明する。図８〜図１１において、特に記載の無い限り、各行の先頭の数字は説明のための行番号を示し、続くコロン（：）でデータ本体を示すコードと区別されている。また、図８〜図１１に例示されるコードは、データ記述言語の１つであるＪＳＯＮ(JavaScript Object Notation、JavaScriptは登録商標)を模した模擬コードである。このコードにおいては、１対の前括弧「｛」および後括弧「｝」で挟んだ部分に、前括弧「｛」の直前に記述される項目の内容が記述される。

定義情報は、複数のＡＰＩの定義を含むことができる。図８は、ＡＰＩ機能２０１を定義するためのスキーマ情報の一例を示す。なお、スキーマ情報３００は、リクエストおよびレスポンスのスキーマ定義を複数含むことができ、図８では、これら複数のスキーマ定義に共通して定義される共通情報定義部を抽出して示している。

図８において、スキーマ情報３００の共通情報定義部は、１行目および２行目にパス情報が記述され、３行目〜５行目にヘッダ情報が記述される。６行目にリソース定義であることが記述され、７行目は、このＡＰＩの名前が記述される。この７行目に記述される名前のＡＰＩの機能が、８行目の項目「ｍｅｔｈｏｄ」の直後の前括弧「｛」と、対応する２３行目の後括弧「｝」との間に記述される。すなわち、項目「ｍｅｔｈｏｄ」の直後の前括弧「｛」から対応する後括弧「｝」までの間は、１のＡＰＩの情報が定義されるＡＰＩ定義部分である。このＡＰＩ定義部分の記述を繰り返すことで、スキーマ情報３００により複数のＡＰＩを定義することができる。

９行目は、ＡＰＩ機能の名前が記述される。１０行目および１１行目は、機能毎のパス情報と、ＡＰＩ機能を使用するためのＨＴＴＰ(Hypertext Transfer Protocol)メソッドの種類（ＧＥＴ／ＰＵＴ）が記述される。

１２行目の項目「ｒｅｑｕｅｓｔ」は、以下にＡＰＩのリクエストのスキーマ定義が記述されることが記述され、１３行目〜１５行目に、リクエストのスキーマ定義の本体が記述される。リクエストのスキーマ定義の本体については、後述する。なお、リクエストのスキーマ定義は、通常、複数行に亘って記述されるが、図８の例では、説明のため、１４行目の１行で表現している。

１７行目の項目「ｒｅｓｐｏｎｓｅ」は、以下のＡＰＩのレスポンスのスキーマ定義が記述されることが記述される。１８行目〜２０行目に、レスポンスのスキーマ定義の本体が記述される。レスポンスのスキーマ定義の本体については、後述する。上述と同様に、レスポンスのスキーマ定義は、通常、複数行に亘って記述されるが、図８の例では、説明のため、１９行目の１行で表現している。

図９〜図１１は、第１の実施形態に係るスキーマ定義の例を示す。図９が文字列として定義されるスキーマ定義の例、図１０が配列として定義されるスキーマ定義の例、図１１がオブジェクトとして定義されるスキーマ定義の例を示す。図１１の例は、階層構造を用いてスキーマ定義を記述したい場合に用いられる。

図９において、図９（ａ）は、リクエストのスキーマ定義３１０の例を示し、図９（ｂ）は、このリクエストのスキーマ定義３１０に対応するレスポンスのスキーマ定義３１１の例を示す。

図９（ａ）において、リクエストのスキーマ定義３１０は、同一のレベルの括弧「｛」および「｝」の組で挟まれた部分に、リクエストの形式が定義され、当該括弧の組の前括弧「｛」の直前に、当該リクエストの名称が記述される。このリクエストの名称が、リクエスト毎のキーとして用いられる。図９（ａ）の例では、２行目〜６行目に、キー「ｐａｓｓｗｏｒｄ」に対応するリクエストの値が定義され、７行目〜１１行目に、キー「ｔｅｎａｎｔＩｄ」に対応するリクエストの値が定義される。

また、各キーの直後の行に、このキーに対応するレスポンスの形式が記述される。図９（ａ）の例では、キー「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」の何れも、項目「ｔｙｐｅ」にパラメータ「ｓｔｒｉｎｇ」が記述され、レスポンスの形式が文字列であることが示されている。

図９（ｂ）において、レスポンスのスキーマ定義３１１は、対応するリクエストのスキーマ定義３１０における各キー「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」それぞれに対するレスポンスが定義される。図９（ｂ）の例では、リクエストのキー「ｐａｓｓｗｏｒｄ」に対して、レスポンスとして文字列による値「ｐａｓｓＳａｍｐｌｅ」が定義され、キー「ｔｅｎａｎｔＩｄ」に対して、レスポンスとして文字列による値「ｔｅｎａｎｔＳａｍｐｌｅ」が定義されている。

図１０において、図１０（ａ）は、リクエストのスキーマ定義３２０の例を示し、図１０（ｂ）は、このリクエストのスキーマ定義３２０に対応するレスポンスのスキーマ定義３２１の例を示す。図１０（ａ）のリクエストのスキーマ定義３２０の例では、２行目に、このリクエストの名称としてキー「ｋｅｙｓ」が記述され、３行目の項目「ｔｙｐｅ」にパラメータ「ａｒｒａｙ」が記述され、レスポンスの形式が配列であることが示されている。４行目〜８行目は、この配列の内部の形式が定義され、例えば５行目の項目「ｔｙｐｅ」にパラメータ「ｓｔｒｉｎｇ」が記述され、文字列が用いられることが示されている。

図１０（ｂ）において、レスポンスのスキーマ定義３２１は、対応するリクエストのスキーマ定義３２０におけるキー「ｋｅｙｓ」に対するレスポンスが定義される。この場合、リクエストのスキーマ定義３２０において、キー「ｋｅｙｓ」のレスポンスが配列であることが示されているため、レスポンスのスキーマ定義３２１においても、２行目〜４行目に示されるように、レスポンスとして複数の値「ｋｅｙｓａｍｐｌｅｓ１」、「ｋｅｙｓａｍｐｌｅｓ２」および「ｋｅｙｓａｍｐｌｅｓ３」が定義されている。

図１１において、図１１（ａ）は、リクエストのスキーマ定義３３０の例を示し、図１１（ｂ）は、このリクエストのスキーマ定義３３０に対応するレスポンスのスキーマ定義３３１の例を示す。図１１（ａ）のリクエストのスキーマ定義３３０の例では、２行目に、このリクエストの名称としてキー「ｔｅｎａｎｔ」が記述され、３行目の項目「ｔｙｐｅ」にパラメータ「ｏｂｊｅｃｔ」が記述され、レスポンスの形式がオブジェクトであることが示されている。４行目以降に、例えば図９（ａ）のリクエストのスキーマ定義３１０と同等の、キー「ｐａｓｓｗｏｒｄ」を含む構成が記述される。すなわち、このリクエストのスキーマ定義３３０は、内部にさらにリクエストのスキーマ定義を含み、リクエストのスキーマ定義が階層構造をなし、２つのキーを階層的に含んでいる。

図１１（ｂ）において、レスポンスのスキーマ定義３３１は、図１１（ａ）のリクエストのスキーマ定義３３０に対応し、階層構造をなしている。すなわち、キー「ｔｅｎａｎｔ」のレスポンスの値は、キー「ｐａｓｓｗｏｒｄ」のレスポンスの値「ｐａｓｓＳａｍｐｌｅ」を含む。実際には、このレスポンスのスキーマ定義３３１に従い記述される階層構造を有するレスポンスでは、最下層のキー「ｐａｓｓｗｏｒｄ」の値が参照される。

なお、図９（ａ）の４行目および９行目、図１０（ａ）の６行目、ならびに、図１１（ａ）の７行目に記述される項目「ｒｅｑｕｉｒｅｄ」は、このリクエスト値が必須であるか否が記述される。また、図９（ａ）の５行目および１０行目、図１０（ａ）の７行目、ならびに、図１１（ａ）の８行目に記述される項目「ｄｅｆａｕｌｔ」は、このリクエスト値のデフォルト値が記述される。

また、例えば図９（ａ）に示したリクエストのスキーマ定義３１０は、図８のスキーマ情報３００におけるＡＰＩ定義部分の項目「ｒｅｑｕｅｓｔ」に対応する位置（例えば１４行目）に挿入される。同様に、図９（ｂ）に示したレスポンスのスキーマ定義３１１は、スキーマ情報３００におけるＡＰＩ定義部分の項目「ｒｅｓｐｏｎｓｅ」に対応する位置（例えば１９行目）に挿入される。これは、図１０（ａ）および図１１（ａ）に示される各リクエストのスキーマ定義３２０および３３０、ならびに、図１０（ｂ）および図１１（ｂ）に示される各レスポンスのスキーマ定義３２１および３３１についても同様である。

上述したような各スキーマ定義は、例えば提供者により予めＡＰＩ群２０に、スキーマ情報として格納される。このスキーマ情報をＷｅｂサーバ１０のストレージ１０４に格納しておいてもよい。

（第１の実施形態に係る動作確認ツール）
次に、第１の実施形態に係る動作確認ツールについて説明する。図１２は、第１の実施形態に係る、以下で用いるスキーマ定義の例を概略的に示す。なお、以下では、図７を用いた説明と同様の、第１、第２および第３のＡＰＩ機能２０１が、この順序で用いられるものとする。図１２（ａ）は、第１のＡＰＩ機能２０１に係るスキーマ定義３５０の例、図１２（ｂ）は、第２のＡＰＩ機能２０１に係るスキーマ定義３５１の例、図１２（ｃ）は、第３のＡＰＩ機能２０１に係るスキーマ定義３５２の例をそれぞれ示す。

なお、図１２（ａ）、図１２（ｂ）および図１２（ｃ）に示されるスキーマ定義３５０、３５１および３５２は、それぞれ、図８〜図１１を用いて説明した各スキーマ定義から、第１の実施形態に係る動作確認ツールの動作に関わりの深い部分を抜き出して示している。

図１２（ａ）において、スキーマ定義３５０は、ＨＴＴＰメソッド３５００ａおよびパス情報３５００ｂと、１つのリクエストのスキーマ３５０１と、１つのレスポンスのスキーマ３５０２とを含む。ここで、リクエストのスキーマ３５０１は、キーの値（「ｐａｓｓｗｏｒｄ」）と、入力形式（「ｓｔｒｉｎｇ」）とを含む。レスポンスのスキーマ３５０２も同様に、キーの値と入力形式とを含んでいる。

図１２（ｂ）において、スキーマ情報３５１は、ＨＴＴＰメソッド３５１０ａおよびパス情報５３１０ｂと、それぞれキーの値と入力形式とを含む２つのリクエストのスキーマ３５１１₁および３５１１₂と、キーである１つのレスポンスのスキーマ３５１２とを含む。ここで、リクエストのスキーマ３５１１₁のキーの値（「ｐａｓｓｗｏｒｄ」）は、スキーマ定義３５０のリクエストのスキーマ３５０１と同一である。また、リクエストのスキーマ３５１１₂のキーの値（「ｔｅｎａｎｔＩｄ」）は、スキーマ定義３５０のレスポンスのスキーマ３５０２のキーの値と同一である。すなわち、スキーマ定義３５１のリクエストは、直前のスキーマ定義３５０に依存している。

図１２（ｃ）において、スキーマ情報３５２は、ＨＴＴＰメソッド３５２０ａおよびパス情報３５２０ｂと、それぞれキーの値と入力形式とを含む４つのリクエストのスキーマ３５２１₁、３５２１₂、３５２１₃および３５２１₄と、それぞれキーの値と入力形式とを含む２つのレスポンスのスキーマ３５２２₁および３５２２₂とを含む。ここで、リクエストのスキーマ３５２１₁のキーの値（「ｃｏｏｋｉｅ」）は、スキーマ定義３５１のレスポンスのスキーマ３５１２のキーの値と同一である。また、リクエストのスキーマ３５２１₂のキーの値（「ｔｅｎａｎｔＩｄ」）は、スキーマ定義３５１のリクエストのスキーマ３５１１₂のキーの値と同一である。すなわち、スキーマ定義３５２のリクエストは、直前のスキーマ定義３５１に依存している。

なお、スキーマ情報３５２において、リクエストのスキーマ３５２１₃および３５２１₄のキーの値（「ｋｅｙ」および「Ｖａｌｕｅ」）および入力形式（「ｓｔｒｉｎｇ」）が、レスポンスのスキーマ３５２２₁および３５２２₂にそのまま用いられている。

例えば、提供者は、提供者ＰＣ３０などを用いて、上述の図１２（ａ）、図１２（ｂ）および図１２（ｃ）に示したスキーマ定義３５０〜３５２を含むスキーマ情報３００を作成し、ＡＰＩ群２０内の所定の位置に格納しておく。

次に、第１の実施形態に係るＷｅｂアプリ１１としての動作確認ツールの動作について説明する。図１３は、第１の実施形態に係る動作確認ツールの動作を説明するための一例のフローチャートである。このフローチャートによる各処理は、Ｗｅｂアプリ１１としての動作確認ツールにより実行される。

この図１３のフローチャートによる処理の実行に先立って、動作確認ツールは、ＡＰＩ機能を選択するためのＡＰＩ選択画面を、利用者ＰＣ３１に表示させる。より具体的には、動作確認ツールは、表示情報生成部１００６により、後述するＡＰＩ選択画面を表示させるための表示情報を生成し、生成した表示情報を、Ｗｅｂサーバ１０からネットワーク４０を介して利用者ＰＣ３１に送信する。利用者ＰＣ３１は、この表示情報を受信すると、受信した表示情報に従い、ＡＰＩ選択画面を表示装置１２５に表示させる。

また、動作確認ツールは、例えばＡＰＩ群２０から、利用可能なＡＰＩ機能のリストを取得する。

ステップＳ１００で、動作確認ツールは、ＡＰＩ選択画面に対して入力領域を配置し、配置した入力領域に対して利用可能なＡＰＩ機能のリストを表示させる。そして、動作確認ツールは、入力領域に対する利用者ＰＣ３１からのユーザ操作に応じてＡＰＩ機能を選択する。より具体的には、動作確認ツールにおいて、操作部１００１は、利用者ＰＣ３１からの、ＡＰＩ機能の選択指示を待機し、選択指示を受信すると、受信した選択指示により選択されたＡＰＩ機能を特定する。このとき、動作確認ツールは、特定されたＡＰＩ機能の数に１を加算し、ＡＰＩ機能の数をカウントする。

次のステップＳ１０１で、動作確認ツールは、利用者ＰＣ３１からのユーザ操作を待機し、ユーザ操作を受け付けた場合に、受け付けたユーザ操作がＡＰＩ機能の追加および決定の何れの操作であるかを判定する。動作確認ツールは、受け付けたユーザ操作がＡＰＩ機能の追加の指示の操作であると判定した場合、処理をステップＳ１０２に移行させ、ＡＰＩ機能を追加するために、新たな入力領域をＡＰＩ選択画面に配置する。そして、処理がステップＳ１００に戻され、新たな入力領域に対するユーザ操作を待機する。

一方、動作確認ツールは、ステップＳ１０１で、利用者ＰＣ３１からのユーザ操作が、ＡＰＩ機能の決定の操作であると判定した場合、処理をステップＳ１０３に移行させる。以下のステップＳ１０３〜ステップＳ１０７の処理により、ステップＳ１００〜ステップＳ１０２で選択された各ＡＰＩ機能の動作を確認するための動作確認画面が生成される。このステップＳ１０３〜ステップＳ１０７は、上述のステップＳ１００〜ステップＳ１０２の処理でカウントされたカウント値分、すなわち、選択されたＡＰＩ機能の数だけ繰り返して実行される。

以下では、ステップＳ１００〜ステップＳ１０２の処理により、図１２を用いて説明した、第１、第２および第３のＡＰＩ機能２０１が選択されたものとする。これら第１、第２および第３のＡＰＩ機能２０１には、上述したように、スキーマ定義３５０、３５１および３５２がそれぞれ対応する。

ステップＳ１０３で、動作確認ツールは、取得部１００３により、ステップＳ１００で選択された１つのＡＰＩ機能（例えば第１のＡＰＩ機能２０１）を対象として、例えばＡＰＩ群２０から、スキーマ情報３００に含まれるスキーマ定義（例えばスキーマ定義３５０）を取得する。また、このステップＳ１０３がステップＳ１０３〜ステップＳ１０７で繰り返される処理のうち最初の処理である場合には、動作確認ツールは、取得部１００３により、スキーマ情報３００から共通情報定義部をさらに取得する。

次のステップＳ１０４で、動作確認ツールは、ステップＳ１０３で取得されたスキーマ定義から、ＨＴＴＰメソッドとパス情報とを抽出して動作確認画面に配置する。例えば、対象となるＡＰＩ機能が第１のＡＰＩ機能２０１であれば、図１２（ａ）を参照して、動作確認ツールは、スキーマ定義３５０からＨＴＴＰメソッド３５００ａと、パス情報３５００ｂとを抽出して、動作確認画面の所定の位置に配置する。

また、ステップＳ１０４で、動作確認ツールは、ステップＳ１０３で取得したスキーマ定義から、リクエストのスキーマを抽出して、キーの値を動作確認画面の所定の位置に配置する。例えば、対象となるＡＰＩ機能が第１のＡＰＩ機能２０１であれば、図１２（ａ）を参照して、動作確認ツールは、スキーマ定義３５０からリクエストのスキーマ３５０１を抽出し、キーの値を動作確認画面の所定の位置に配置する。

次のステップＳ１０５で、動作確認ツールは、各スキーマのキーの値に基づき、ステップＳ１０４で配置したリクエストのスキーマと同様の、例えばキーの値が一致するスキーマが動作確認画面に既に配置されているか否かを判定する。動作確認ツールは、配置されていないと判定した場合、処理をステップＳ１０７に移行させる。一方、動作確認ツールは、配置されていると判定した場合、処理をステップＳ１０６に移行させる。

動作確認ツールは、例えば、ステップＳ１０４で配置されたリクエストのスキーマが、動作確認画面に最初に配置されたスキーマである場合には、同様のスキーマが配置されていないと判定する。また例えば、対象となるＡＰＩ機能が第２のＡＰＩ機能２０１であり、第１のＡＰＩ機能２０１に対応するリクエストのスキーマ３５０１が既に配置されている場合、このリクエストのスキーマ３５０１のキーの値「ｐａｓｓｗｏｒｄ」は、第２のＡＰＩ機能２０１のスキーマ定義３５１に含まれるリクエストのスキーマ３５１１₁のキーの値と同一である。したがって、動作確認ツールは、既に配置されていると判定する。さらに例えば、この場合において、スキーマ定義３５１に含まれるリクエストのスキーマ３５１１₂のキーの値「ｔｅｎａｎｔＩｄ」は、リクエストのスキーマ３５０１とは異なるが、レスポンスのスキーマ３５０２のキーの値と一致する。この場合も、動作確認ツールは、同様のスキーマが配置されていると判定する。

ステップＳ１０６で、動作確認ツールは、ステップＳ１０５で同様のスキーマが既に配置されると判定したスキーマの値に対して、自動入力フラグを設定する。この自動入力フラグが設定されたスキーマは、動作確認処理の実行時に、既に配置されている、当該スキーマとキーの値が一致するスキーマの値が自動的に入力される。

例えば、上述のリクエストのスキーマ３５１１₁のキーの値「ｐａｓｓｗｏｒｄ」は、当該リクエストのスキーマ３５１１₁より前に配置されたリクエストのスキーマ３５０１のキーの値と同一である。したがって、リクエストのスキーマ３５１１₁に対して自動入力フラグが設定される。また例えば、上述のリクエストのスキーマ３５１１₂のキーの値「ｔｅｎａｎｔＩｄ」は、当該リクエストのスキーマ３５１１₂より前に配置されたレスポンスのスキーマ３５０２のキーの値と同一である。したがって、リクエストのスキーマ３５１１₂にも、自動入力フラグが設定される。

次のステップＳ１０７で、動作確認ツールは、ステップＳ１００〜ステップＳ１０２で選択された全てのＡＰＩ機能について処理が終了したか否かを判定する。動作確認ツールは、未だ処理が終了していないＡＰＩ機能があると判定した場合、処理をステップＳ１０３に戻す。一方、動作確認ツールは、選択された全てのＡＰＩ機能について処理が終了したと判定した場合、処理をステップＳ１０８に移行させる。

ステップＳ１０８で、動作確認ツールは、ステップＳ１０３〜ステップＳ１０７の処理で生成された動作確認画面を、利用者ＰＣ３１に表示させる。より具体的には、例えば、表示情報生成部１００６は、ステップＳ１０３〜ステップＳ１０７で生成された各配置情報や自動入力フラグを用いて、動作確認画面を表示させるための表示情報を生成する。動作確認ツールは、生成された表示情報を、Ｗｅｂサーバ１０からネットワーク４０を介して利用者ＰＣ３１に送信する。利用者ＰＣ３１は、受信した表示情報に従い、動作確認画面を表示装置１２５に表示させる。

次のステップＳ１０９で、動作確認ツールは、利用者ＰＣ３１からの実行指示を待機する。動作確認ツールは、利用者ＰＣ３１からの実行指示を受信すると、上述の処理で生成された動作確認画面に従い、動作確認処理を実行する。動作確認処理の詳細については、後述する。

次に、動作確認ツールにより上述のステップＳ１００〜ステップＳ１０２で生成されるＡＰＩ選択画面と、ステップＳ１０３〜ステップＳ１０７で生成される動作確認画面について、より具体的に説明する。図１４は、ステップＳ１００〜ステップＳ１０２で動作確認ツールに生成される、第１の実施形態に係るＡＰＩ選択画面の例を示す。図１４に示されるＡＰＩ選択画面３６０は、利用したいＡＰＩの機能を選択して追加するための選択部として機能する。

動作確認ツールは、ＡＰＩ選択画面３６０を表示させるための表示情報を生成して、例えばＷｅｂサーバ１０からネットワーク４０を介して利用者ＰＣ３１に送信する。利用者ＰＣ３１は、Ｗｅｂサーバ１０から送信された表示情報を受信し、受信した表示情報に応じて、ＡＰＩ選択画面３６０を表示装置１２５により表示させる。利用者は、この表示に従い利用者ＰＣ３１の入力デバイス１２８を操作することで、ＡＰＩ選択画面３６０に従った指示を、Ｗｅｂサーバ１０に送信することができる。

図１４において、ＡＰＩ選択画面３６０は、選択領域３６００₁、３６００₂および３６００₃が設けられ、各領域において、既にＡＰＩの機能「サービス登録ＡＰＩ」、「テナント認証ＡＰＩ」および「key、value登録ＡＰＩ」がそれぞれ選択済みの状態となっている。各選択領域３６００₁〜３６００₃は、例えば右端に表示される三角印をユーザ操作により指定することで、リスト表示３６０１のように、選択可能なＡＰＩ機能のリストが表示される。

なお、決定ボタン３６０３は、各選択領域３６００₁〜３６００₃による選択内容を確定し、次の処理に移行するためのボタンである。

さらに、図１４の例では、選択領域３６００₃の右側に、ＡＰＩ機能を追加するための追加ボタン３６０２が配置される。このボタン３６０２を操作することで、ＡＰＩ選択画面３６０に、ＡＰＩ機能を選択するための選択領域を追加することができる。

例えば、動作確認ツールは、ＡＰＩ選択画面３６０に対し、初期状態では、空白（未選択状態）の選択領域３６００₁と、追加ボタン３６０２と、決定ボタン３６０３とを設ける。動作確認ツールは、例えば利用者ＰＣ３１から、選択領域３６００₁に対するＡＰＩ機能の選択操作が行われ、追加ボタン３６０２が操作された旨の通知を受けると、選択領域３６００₁の下に選択領域３６００₂を追加して表示させ、追加ボタン３６０２の位置を選択領域３６００₁の右側から、追加された選択領域３６００₂の右側に移動させ、選択領域３６００₂の追加と、追加ボタン３６０２の位置の変更を行う。このようにして、ＡＰＩ選択画面３６０に対して、選択領域を順次追加することができる。

また、動作確認ツールは、例えば選択領域３６００₁の右側に設けられる三角印が操作されると、例えば図１３のフローチャートの処理に先立って取得部１００３に取得されたＡＰＩ機能のリストに基づき、ＡＰＩ機能を選択するためのリスト表示３６０１を生成する。

さらに、ＡＰＩ選択画面３６０において複数のＡＰＩ機能が選択された場合、当該複数のＡＰＩ機能が適用される順序を、当該ＡＰＩ選択画面３６０上で指定することができる。

例えば、動作確認ツールは、ＡＰＩ選択画面３６０において、選択されたＡＰＩ機能が表示される位置に応じて、ＡＰＩ機能が適用される順序を指定する。図１４の例では、ＡＰＩ選択画面３６０の上から順に配置される選択領域３６００₁、３６００₂および３６００₃に、それぞれ機能「サービス登録ＡＰＩ」、「テナント認証ＡＰＩ」および「key、value登録ＡＰＩ」が表示されている。そこで、動作確認ツールは、各ＡＰＩ機能の適用順を、この表示順に合わせて、機能「サービス登録ＡＰＩ」、機能「テナント認証ＡＰＩ」、機能「key、value登録ＡＰＩ」の順とする。

なお、各選択領域３６００₁、３６００₂および３６００₃は、それぞれ右側に設けられる三角印を操作することで、リスト表示３６０１と同様にして、選択可能なＡＰＩ機能のリストが表示される。このリストにおいて所望のＡＰＩ機能を指定することで、対応する選択領域に表示されるＡＰＩ機能が指定されたＡＰＩ機能に切り替わり、指定されるＡＰＩ機能が更新される。また、これにより、ＡＰＩ機能が適用される順序を変更することができる。

動作確認ツールは、ＡＰＩ選択画面３６０において決定ボタン３６０３が操作されると、ＡＰＩ選択画面３６０において選択された各ＡＰＩ機能による動作を確認するための動作確認画面を生成する。図１５は、ステップＳ１０３〜ステップＳ１０７で動作確認ツールに生成される、第１の実施形態に係る動作確認画面の例を示す。図１５において、動作確認画面３６１ａは、ＡＰＩ選択画面３６０において各選択領域３６００₁、３６００₂および３６００₃にて指定された各ＡＰＩ機能にそれぞれ対応するＡＰＩ機能領域３６１０ａ₁、３６１０ａ₂および３６１０ａ₃が設けられる。

これらＡＰＩ機能領域３６１０ａ₁、３６１０ａ₂および３６１０ａ₃は、それぞれ、各ＡＰＩ機能におけるＨＴＴＰメソッドに関する情報と、リクエストに関する情報および入力領域とが表示される。

例えば、動作確認ツールは、ＡＰＩ選択画面３６０での決定ボタン３６０３の操作に応じて、各選択領域３６００₁〜３６００₃において指定されたＡＰＩ機能に従い、ＡＰＩ群２０から、指定されたＡＰＩ機能に関するスキーマ定義を含むスキーマ情報３００を取得する。動作確認ツールは、取得したスキーマ情報３００から、所定の項目の値と各キーの値とを取得する。動作確認ツールは、取得した各値に基づき、動作確認画面３６１ａにおいてＡＰＩ機能に対してリクエストを生成するための入力領域などを生成する。

この例では、動作確認ツールは、図１２（ａ）、図１２（ｂ）および図１２（ｃ）に示したスキーマ定義３５０、３５１および３５２を含むスキーマ情報３００を取得するものとする。動作確認ツールは、取得したスキーマ情報３００に基づき、各ＡＰＩ機能領域３６１０ａ₁、３６１０ａ₂および３６１０ａ₃を表示するための表示情報を生成する。

図１５の例では、ＡＰＩ機能領域３６１０ａ₁に対して、スキーマ定義３５０に含まれるＨＴＴＰメソッド３５００ａおよびパス情報３５００ｂに対応する値３６１１₁と、スキーマ定義３５０に含まれるリクエストのスキーマ３５０１のキーの値（「ｐａｓｓｗｏｒｄ」）に対応する値が入力される入力領域３６１２ａ₁₁とが配置される。ここで、ＡＰＩ機能領域３６１０ａ₁に対応するＡＰＩ機能は、ＡＰＩ選択画面３６０において指定される各ＡＰＩ機能のうち最初に適用されるＡＰＩ機能であり、参照すべき値が存在しない。そのため、入力領域３６１２ａ₁₁は、デフォルトの値が予め入力される。この入力領域３６１２ａ₁₁は、例えば利用者ＰＣ３１に対するユーザ操作に応じて、任意の値を入力することができる。

ＡＰＩ機能領域３６１０ａ₂は、スキーマ定義３５１に含まれるＨＴＴＰメソッド３５１０ａおよびパス情報３５１０ｂに対応する値３６１１₂と、スキーマ定義３５１に含まれるリクエストのスキーマ３５１１₁および３５１１₂のキーの値（「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」）に対応する値が入力される入力領域３６１２ａ₂₁および３６１２ａ₂₂とが配置される。

この場合、上述したように、リクエストのスキーマ３５１１₁には自動入力フラグが設定されている。そのため、入力領域３６１２ａ₂₁の値として、順序が前のＡＰＩ機能に対応するスキーマ定義３５０におけるリクエストのスキーマ３５０１の値が適用される。また、リクエストのスキーマ３５１１₂には自動入力フラグが設定されている。そのため、入力領域３６１２ａ₂₂の値として、順序が前のＡＰＩ機能に対応するスキーマ定義３５０におけるレスポンスのスキーマ３５０２の値が適用される。

ＡＰＩ機能領域３６１０ａ₃は、スキーマ定義３５２に含まれるＨＴＴＰメソッド３５２０に対応する値３６１１₃と、スキーマ定義３５２に含まれるリクエストのスキーマ３５２１₁、３５２１₂、３５２１₃および３５２１₄のキーの値（「ｃｏｏｋｉｅ」、「ｔｅｎａｎｔＩｄ」、「ｋｅｙ」および「ｖａｌｕｅ」）に対応する値が入力される入力領域３６１２ａ₃₁、３６１２ａ₃₂、３６１２ａ₃₃および３６１２ａ₃₄とが配置される。

この場合、リクエストのスキーマ３５２１₁には、自動入力フラグが設定されている。そのため、入力領域３６１２ａ₃₁の値として、順序が前のＡＰＩ機能に対応するスキーマ定義３５１におけるレスポンスのスキーマ３５１２の値が適用される。また、リクエストのスキーマ３５２１₂には、自動入力フラグが設定されている。そのため、入力領域３６１２ａ₃₂の値は、当該スキーマ定義３５１に含まれるキーであるリクエストのスキーマ３５１１₂の値が適用される。

さらに、リクエストのスキーマ３５２１₃および３５２１₄は、新規に出現した項目であり、対応する入力領域３６１２ａ₃₃および３６１２ａ₃₄は、参照すべき値が存在しない。そのため、動作確認ツールは、入力領域３６１２ａ₃₃および３６１２ａ₃₄に対して、デフォルトの値を入力する。これら入力領域３６１２ａ₃₃および３６１２ａ₃₄は、例えば利用者ＰＣ３１に対するユーザ操作に応じて、任意の値を入力することができる。

このように、第１の実施形態に係る動作確認画面３６１ａは、順序が前のＡＰＩ機能のリクエストまたはレスポンスに対して依存関係があるリクエストについて、この依存関係にあるリクエストまたはレスポンスの値を適用するようにしている。また順序が先頭のＡＰＩ機能のリクエストや、ＡＰＩ機能の順序中、新規に出現したキーに係るリクエストについては、ユーザ操作に応じて値を入力するようにしている。

動作確認画面３６１ａにおいて、実行ボタン３６２０は、動作確認画面３６１ａの各入力領域に入力された値に従い、各ＡＰＩ機能の動作を確認するための動作確認処理を実行させるためのボタンである。

次に、実行ボタン３６２０が操作され、動作確認処理が実行された場合、すなわち、動作確認ツールが、図１３のフローチャートのステップＳ１０９において、利用者ＰＣ３１からの実行指示を受け取った場合の動作確認ツールの動作について説明する。

図１６は、第１の実施形態に係る動作確認ツールによるＡＰＩ機能の動作確認処理を示す一例のフローチャートである。ステップＳ１２０で、動作確認ツールは、処理対象のＡＰＩ機能の数を取得する。ＡＰＩ機能の数は、上述の図１３のフローチャートにおける上述のステップＳ１００〜ステップＳ１０２の処理でカウントされたカウント値から知ることができる。

以下のステップＳ１２１〜ステップＳ１２７の処理は、取得されたＡＰＩ機能の数の回数だけ繰り返される。例えば、ステップＳ１２１〜ステップＳ１２７の処理は、図１５を用いて説明した動作確認画面３６１ａの各ＡＰＩ機能領域３６１０ａ_１〜３６１０ａ_３毎に実行される。

次のステップＳ１２１で、動作確認ツールは、処理の対象となるＡＰＩ機能領域のリクエストのスキーマに自動入力フラグが設定されているか否かを判定する。

動作確認ツールは、自動入力フラグが設定されていると判定した場合、処理をステップＳ１２２に移行させる。ステップＳ１２２で、動作確認ツールは、同一のスキーマを有する、順序が前のＡＰＩ機能領域に既に入力または設定されているリクエストまたはレスポンスの値から、処理対象のＡＰＩ機能領域のリクエストを生成する。動作確認ツールは、リクエストを生成すると、処理をステップＳ１２４に移行させる。

例えば、図１５の動作確認画面３６１ａにおいて、ＡＰＩ機能領域３６１０ａ₂の入力領域３６１２ａ₂₁および３６１２ａ₂₂は、図１３のステップＳ１０６にて説明したように、それぞれ対応するリクエストのスキーマ３５１１₁および３５１１₂に自動入力フラグが設定されている。したがって、入力領域３６１２ａ₂₁には、対応するリクエストのスキーマ３５１１₁とキー値が一致するリクエストのスキーマ３５０１の値から、リクエストのスキーマを生成する。同様に、入力領域３６１２ａ₂₂には、対応するリクエストのスキーマ３５１１₂とキー値が一致するレスポンスのスキーマ３５０２の値から、リクエストのスキーマを生成する。

一方、動作確認ツールは、ステップＳ１２１で自動入力フラグが設定されていないと判定した場合、処理をステップＳ１２３に移行させる。ステップＳ１２３で、動作確認ツールは、ユーザ操作により入力された値からリクエストを生成する。動作確認ツールは、ユーザ操作により利用者ＰＣ３１に対して入力された値を受信すると、受信した値からリクエストを生成し、処理をステップＳ１２４に移行させる。

例えば、図１５の動作確認画面３６１ａにおいて、ＡＰＩ機能領域３６１０ａ₁の入力領域３６１２ａ₁₁は、最初に登場するＡＰＩ機能に対応し、自動入力フラグが設定されていない。また、ＡＰＩ機能領域３６１０ａ₃の入力領域３６１２ａ₃₃および３６１２ａ₃₄は、ここまでのＡＰＩ機能の順序において最初に登場するキーに係るため、自動入力フラグが設定されていない。そのため、これらの入力領域３６１２ａ₁₁、３６１２ａ₃₃および３６１２ａ₃₄は、ユーザ操作により値を入力する必要がある。

ステップＳ１２４で、動作確認ツールは、ステップＳ１２２またはステップＳ１２３で生成したリクエストを、例えばＡＰＩ群２０に送信する。動作確認ツールは、送信したリクエストに対するレスポンスをステップＳ１２５で受信し、処理をステップＳ１２６に移行させる。

ステップＳ１２６で、動作確認ツールは、ステップＳ１２４で送信したリクエストを示すリクエスト情報と、ステップＳ１２５で受信したレスポンスを示すレスポンス情報とを表示させるための表示情報を生成する。次のステップＳ１２７で、動作確認ツールは、対象となる全てのＡＰＩ機能について処理が終了したか否かを判定する。動作確認ツールは、未だ処理が終了していないＡＰＩ機能があると判定した場合、処理をステップＳ１２１に戻し、次のＡＰＩ機能を処理対象として、処理を開始する。

一方、動作確認ツールは、ステップＳ１２７で、対象となる全てのＡＰＩ機能について処理が終了したと判定した場合、処理をステップＳ１２８に移行させる。ステップＳ１２８で、動作確認ツールは、各ＡＰＩ機能についてステップＳ１２６で生成した、動作確認結果としてのリクエスト情報およびレスポンス情報を表示させるための表示情報を、処理対象のＡＰＩ機能全てについて纏めて、利用者ＰＣ３１に送信する。利用者ＰＣ３１は、この表示情報に基づき、例えば表示装置１２５にリクエスト情報およびレスポンス情報を表示させる。

図１７は、第１の実施形態に係る、リクエスト情報およびレスポンス情報の表示例を示す。図１７（ａ）は、リクエスト情報およびレスポンス情報の構造の例を示す。図１７（ａ）において、リクエスト情報３７００は、１つのＡＰＩ機能＃１について、リクエストホスト、リクエストヘッダおよびリクエストボディを含む。レスポンス情報３７０１についても同様に、１つのＡＰＩ機能＃１について、レスポンスホスト、レスポンスヘッダおよびレスポンスボディを含む。１つのＡＰＩ機能について、これらリクエスト情報３７００とレスポンス情報３７０１とが１対１に対応付けられた組として構成される。

図１７（ｂ）は、表示情報により表示される結果情報３７０の例を示す。結果情報３７０は、ＡＰＩ選択画面３６０で指定された全てのＡＰＩ機能に対するレスポンス情報およびレスポンス情報の組を含む。図１７（ｂ）の例では、結果情報は、ＡＰＩ選択画面３６０で指定されたＡＰＩ機能の順序に従い、第１のＡＰＩ機能２０１に係るリクエスト情報３７００₁とレスポンス情報３７０１₁の組、第１のＡＰＩ機能２０１に係るリクエスト情報３７００₂とレスポンス情報３７０１₂の組、…のように、ＡＰＩ選択画面３６０で指定された全てのＡＰＩ機能に対するレスポンス情報およびレスポンス情報が纏めて表示される。

このように、第１の実施形態では、依存関係のある複数のＡＰＩ機能の動作結果を纏めて表示するようにしているので、容易に動作確認を行うことができる。

（第２の実施形態）
次に、第２の実施形態について説明する。上述した第１の実施形態による動作確認画面３６１ａでは、順序が前のＡＰＩ機能のリクエストまたはレスポンスに対して依存関係があるリクエストについては、当該順序が前のＡＰＩ機能のリクエストまたはレスポンスの値を自動的に適用するようにしていた。これに対して、第２の実施形態は、順序が前のＡＰＩ機能のリクエストまたはレスポンスに対して依存関係があるリクエストについて、ユーザ操作により値を入力、または、値を選択可能とし、より汎用に構成した例である。

図１８は、第２の実施形態に係る動作確認画面の例を示す。なお、図１８において、上述した図１５と共通する部分には同一の符号を付して、詳細な説明を省略する。図１８に示される動作確認画面３６１ｂは、上述した動作確認画面３６１ａに対して、各入力領域を、ユーザ操作による直接的な入力、または、ユーザ操作による入力値の選択が可能なように構成している。

例えば、図１８の例では、動作確認画面３６１ｂにおいて、各ＡＰＩ機能領域は、キーとなるリクエスト毎に、直接入力領域と選択入力領域とが配置される。具体的には、例えばＡＰＩ機能領域３６１０ａ₂’において、キー「ｐａｓｓｗｏｒｄ」のリクエスト入力領域として、直接入力領域３６１２ａ₂₁−１と選択入力領域３６１２ａ₂₁−２とが配置され、キー「ｔｅｎａｎｔＩｄ」のリクエスト入力領域として、直接入力領域３６１２ａ₂₂−１と選択入力領域３６１２ａ₂₂−２とが配置される。選択入力領域３６１２ａ₂₁−２および３６１２ａ₂₂−２は、それぞれ、順序が前の第１のＡＰＩ機能２０１のスキーマ定義３５０に定義される各キー「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」とが選択できるようになっている。

ＡＰＩ機能領域３６１０ａ₃’についても同様である。すなわち、ＡＰＩ機能領域３６１０ａ₃’において、キー「ｃｏｏｋｉｅ」のリクエスト入力領域として、直接入力領域３６１２ａ₃₁−１と選択入力領域３６１２ａ₃₁−２とが配置され、キー「ｔｅｎａｎｔＩｄ」のリクエスト入力領域として、直接入力領域３６１２ａ₃₂−１と選択入力領域３６１２ａ₃₂−２とが配置される。これら選択入力領域３６１２ａ₃₁−２および３６１２ａ₃₂−２は、順序が前の第１のＡＰＩ機能２０１のスキーマ定義３５０に定義されるキー「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」と、同様に順序が前の第２のＡＰＩ機能２０１のスキーマ定義３５１に定義されるキー「ｃｏｏｋｉｅ」とが選択できるようになっている。

図１９は、第２の実施形態に係る動作確認ツールの動作を説明するための一例のフローチャートである。このフローチャートによる各処理は、Ｗｅｂアプリ１１としての動作確認ツールにより実行される。この図１９のフローチャートによる処理の実行に先立って、動作確認ツールは、ＡＰＩ機能を選択するためのＡＰＩ選択画面を、利用者ＰＣ３１に表示させる。このＡＰＩ選択画面は、図１４を用いて説明したＡＰＩ選択画面３６０と共通できるので、ここでの説明を省略する。

ステップＳ２００で、動作確認ツールは、ＡＰＩ選択画面に対して入力領域を配置し、配置した入力領域に対して利用可能なＡＰＩ機能のリストを表示させる。そして、動作確認ツールは、入力領域に対する利用者ＰＣ３１からのユーザ操作に応じてＡＰＩ機能を選択する。また、動作確認ツールは、特定されたＡＰＩ機能の数に１を加算し、ＡＰＩ機能の数をカウントする。

次のステップＳ２０１で、動作確認ツールは、利用者ＰＣ３１から受け付けたユーザ操作がＡＰＩ機能の追加および決定の何れの操作であるかを判定する。動作確認ツールは、受け付けたユーザ操作がＡＰＩ機能の追加の指示の操作であると判定した場合、処理をステップＳ２０２に移行させ、ＡＰＩ機能を追加するために、新たな入力領域をＡＰＩ選択画面に配置する。そして、処理がステップＳ２００に戻され、新たな入力領域に対するユーザ操作を待機する。

一方、動作確認ツールは、ステップＳ２０１で、利用者ＰＣ３１からのユーザ操作が、ＡＰＩ機能の決定の操作であると判定した場合、処理をステップＳ２０３に移行させる。以下のステップＳ２０３〜ステップＳ２０８の処理により、第２の実施形態係る動作確認画面３６１ｂが生成される。このステップＳ２０３〜ステップＳ２０８は、上述のステップＳ２００〜ステップＳ２０２の処理でカウントされたカウント値に従い、選択されたＡＰＩ機能の数だけ繰り返して実行される。

以下では、ステップＳ２００〜ステップＳ２０２の処理により、図１２を用いて説明した、第１、第２および第３のＡＰＩ機能２０１が選択されたものとする。

ステップＳ２０３で、動作確認ツールは、ステップＳ２００で選択された１つのＡＰＩ機能（例えば第１のＡＰＩ機能２０１）を対象として、例えばＡＰＩ群２０から、スキーマ情報３００に含まれるスキーマ定義（例えばスキーマ定義３５０）を取得する。また、このステップＳ２０３がステップＳ２０３〜ステップＳ２０８で繰り返される処理の内最初の処理である場合には、動作確認ツールは、スキーマ情報３００から共通情報定義部をさらに取得する。

次のステップＳ２０４で、動作確認ツールは、ステップＳ２０３で取得されたスキーマ定義から、ＨＴＴＰメソッドとパス情報とを抽出して動作確認画面に配置する。また、ステップＳ２０４で、動作確認ツールは、ステップＳ２０３で取得したスキーマ定義から、リクエストのスキーマを抽出して、キーの値を動作確認画面の所定の位置に配置する。次のステップＳ２０５で、動作確認ツールは、ステップＳ２０４で抽出したリクエストのスキーマに基づき、値を入力する入力領域を生成し、この入力領域に対する入力形式を設定する。

次のステップＳ２０６で、動作確認ツールは、現在の処理がステップＳ２０３〜ステップＳ２０８のループ処理の１回目の処理であるか否かを判定する。動作確認ツールは、１回目の処理であると判定した場合、処理をステップＳ２０８に移行させる。一方、動作確認ツールは、現在の処理が１回目ではないと判定した場合、処理をステップＳ２０７に移行させる。ステップＳ２０７で、動作確認ツールは、ステップＳ２０５で生成した入力領域に対して、選択領域を追加し、選択形式を設定する。

次のステップＳ２０７で、動作確認ツールは、ステップＳ２００〜ステップＳ２０２で選択された全てのＡＰＩ機能について処理が終了したか否かを判定する。動作確認ツールは、未だ処理が終了していないＡＰＩ機能があると判定した場合、処理をステップＳ２０３に戻す。一方、動作確認ツールは、選択された全てのＡＰＩ機能について処理が終了したと判定した場合、処理をステップＳ２０９に移行させる。

ステップＳ２０９で、動作確認ツールは、ステップＳ２０３〜ステップＳ２０８の処理で生成された動作確認画面３６１ｂを、利用者ＰＣ３１に表示させる。次のステップＳ２１０で、動作確認ツールは、利用者ＰＣ３１からの実行指示を待機する。動作確認ツールは、利用者ＰＣ３１からの実行指示を受信すると、上述の処理で生成された動作確認画面に従い、動作確認処理を実行する。

例えば、利用者は、この動作確認画面３６１ｂに従い、各ＡＰＩ機能領域に設けられた各入力領域および選択領域に対する入力または選択操作を行う。利用者ＰＣ３１は、動作確認画面３６１ｂの実行ボタン３６２０が操作されると、入力操作および選択操作により入力または選択された各値と、確認動作処理の実行の指示とを、利用者ＰＣ３１からＷｅｂサーバ１０に送信する。Ｗｅｂサーバ１０は、利用者ＰＣ３１から受信した各値を動作確認ツールに渡す。

なお、動作確認ツールにおける動作確認処理は、図１６を用いて説明した処理と同様であり、動作確認処理の結果得られるリクエスト情報およびレスポンス情報は、図１７で説明した構成と同様であるので、それぞれ、ここでの説明を省略する。

このように、第２の実施形態では、各リクエストの値を直接的に入力可能であると共に、順序が前のＡＰＩ機能のリクエストおよびレスポンスのスキーマに基づき選択可能とされているため、ＡＰＩ機能の動作確認をより柔軟に実行できる。

（第２の実施形態の変形例）
次に、第２の実施形態の変形例について説明する。第２の実施形態の変形例は、上述した第２の実施形態に係る動作確認画面３６１ｂにおいて設定された各値を保存可能としたものである。図２０は、第２の実施形態の変形例に係る動作確認画面の例を示す。なお、図２０において、上述した図１８と共通する部分には同一の符号を付して、詳細な説明を省略する。

図２０において、動作確認画面３６１ｂ’は、図１８の動作確認画面３６１ｂに対して保存ボタン３６３０および読み出しボタン３６３１が追加されている。保存ボタン３６３０は、動作確認画面３６１ｂ’の各入力領域および選択領域の状態を保存するためのボタンである。

動作確認ツールは、利用者ＰＣ３１にて保存ボタン３６３０が操作されると、動作確認画面３６１ｂ’の各入力領域３６１２ａ₁₁、３６１２ａ₂₁−１、３６１２ａ₂₂−１、３６１２ａ₃₁−１、３６１２ａ₃₂−１、３６１２ａ₃₃および３６１２ａ₃₄に入力された値を保存する。また、動作確認ツールは、保存ボタン３６３０が操作されると、動作確認画面３６１ｂ’の各選択領域３６１２ａ₂₁−２、３６１２ａ₂₂−２、３６１２ａ₃₁−２および３６１２ａ₃₂−２の選択状態を示す情報を保存する。

動作確認ツールは、これら各入力値と選択状態を示す情報とを、例えば利用者ＰＣ３１のストレージ１２６に保存する。これに限らず、動作確認ツールは、これら各入力値と選択状態を示す情報とを、例えば利用者ＰＣ３１を利用する利用者の識別情報と関連付けて、Ｗｅｂサーバ１０のストレージ１０４に保存してもよい。

読み出しボタン３６３１は、保存ボタン３６３０の操作により保存された各入力値と各選択状態を示す情報とを読み出して、読み出した値などを動作確認画面３６１ｂ’に設定するためのボタンである。動作確認ツールは、利用者ＰＣ３１にて読み出しボタン３６３１が操作されると、保存ボタン３６３０の操作により保存された各入力値と各選択状態を示す情報とを読み出す。

そして、動作確認ツールは、読み出した各入力値と各選択状態を示す情報とを用いて、動作確認画面３６１ｂ’の入力領域３６１２ａ₁₁、３６１２ａ₂₁−１、３６１２ａ₂₂−１、３６１２ａ₃₁−１、３６１２ａ₃₂−１、３６１２ａ₃₃および３６１２ａ₃₄、ならびに、選択領域３６１２ａ₂₁−２、３６１２ａ₂₂−２、３６１２ａ₃₁−２および３６１２ａ₃₂−２の値をそれぞれ設定する。これら設定された値は、利用者ＰＣ３１に対するユーザ操作により変更することも可能である。動作確認画面３６１ｂ’において、実行ボタン３６２０を操作することで、読み出され設定された各値に基づき図１６のフローチャートに従い動作確認処理が実行され、動作確認結果が利用者ＰＣ３１に表示される。

このように、第２の実施形態の変形例に係る動作確認画面３６１ｂ’は、ユーザ操作により入力および選択した各値を保存し、また、保存した各値を読み出して再設定することができる。そのため、利用者は、例えばＡＰＩ機能による動作確認を繰り返して実行するような場合に、各値の入力や選択操作を一々行う必要がなく、動作確認処理の利用者の負荷を軽減することができる。

（第３の実施形態）
次に、第３の実施形態について説明する。上述した第１の実施形態に係る動作確認ツールでは、動作確認の対象のＡＰＩ機能を、ＡＰＩ選択画面３６０において１つずつ指定していた。これに対して、第３の実施形態に係る動作確認ツールは、リクエストのスキーマに依存関係があるＡＰＩ機能の組を予め登録しておき、登録された組に対する利用者の選択に応じて、候補の組を利用者に提示する。このようにすることで、利用者は、候補として提示されたＡＰＩ機能の組から所望の組を選択することで、動作確認の対象の複数のＡＰＩ機能を指定することができる。

第３の実施形態による動作確認ツールの動作について、より詳細に説明する。先ず、例えばＡＰＩ機能の提供者は、リクエストのスキーマに依存関係があるＡＰＩ機能の組を予め作成し、例えばＡＰＩ群２０に格納しておく。式（１）〜（４）は、リクエストのスキーマに依存関係があるＡＰＩ機能の組の例を示す。
｛テナント認証、ｋｅｙ,ｖａｌｕｅ登録｝ …（１）
｛サービス登録、テナント認証、ｋｅｙ,ｖａｌｕｅ登録｝ …（２）
｛テナント認証、ファイル登録｝ …（３）
｛サービス登録、テナント認証、ファイル登録｝ …（４）

なお、式（１）〜（４）において、括弧「｛」および「｝」内の各ＡＰＩ機能の順序は、ＡＰＩ機能が適用される順序を示している。

図２１は、第３の実施形態に係るＡＰＩ選択画面の例を示す。図２１（ａ）は、目的のＡＰＩ機能、例えば一連の処理に最終的に必要となるＡＰＩ機能を選択するための第１のＡＰＩ選択画面４００の例を示す。また、図２１（ｂ）は、第１のＡＰＩ選択画面で選択されたＡＰＩ機能に基づく、リクエストのスキーマに依存関係のあるＡＰＩ機能の組を選択するための第２のＡＰＩ選択画面４０１の例を示す。

なお、第３の実施形態に係る動作確認ツールは、これら第１のＡＰＩ選択画面４００および第２のＡＰＩ選択画面４０１を、例えば図１３のフローチャートにおけるステップＳ１００〜ステップＳ１０２、または、図１９のフローチャートにおけるステップＳ２００〜ステップＳ２０２の処理の代わりに生成し、利用者ＰＣ３１に表示させる。動作確認ツールは、第１のＡＰＩ選択画面４００の生成に先立って、例えばＡＰＩ群２０から、利用可能なＡＰＩ機能のリストを取得する。

図２１（ａ）において、第１のＡＰＩ選択画面４００は、選択領域４０００と、候補ボタン４００２とが配置される。選択領域４０００は、例えば右端に表示される三角印をユーザ操作により指定することで、リスト表示４００１のように、選択可能なＡＰＩ機能のリストが表示される。

動作確認ツールは、例えば利用者ＰＣ３１に対するユーザ操作により、リスト表示４００１に対して目的とするＡＰＩ機能が指定され、候補ボタン４００２が操作されると、リクエストのスキーマに依存関係があるＡＰＩ機能の組のうち、指定されたＡＰＩ機能を含む組を抽出する。例えば、図２１（ａ）に例示されるように、ＡＰＩ機能「ｋｅｙ，ｖａｌｕｅ登録」が指定された場合、動作確認ツールは、上述した式（１）〜（４）から、指定されたＡＰＩ機能「ｋｅｙ，ｖａｌｕｅ登録」を含む組として、式（１）および式（２）で示される組を抽出する。

動作確認ツールは、第１のＡＰＩ選択画面４００において指定されたＡＰＩ機能を含む組を抽出すると、図２１（ｂ）に示す第２のＡＰＩ選択画面４０１を生成し、利用者ＰＣ３１に表示させる。図２１（ｂ）の例では、第２のＡＰＩ選択画面４０１は、抽出されたＡＰＩ機能の組に従い、ＡＰＩ機能表示領域４０１０ａおよび４０１０ｂと、これらＡＰＩ機能表示領域４０１０ａおよび４０１０ｂのうち１つを選択するためのラジオボタン４０１１ａおよび４０１１ｂと、決定ボタン４０１２とが配置される。

ＡＰＩ機能表示領域４０１０ａおよび４０１０ｂは、それぞれ、第１のＡＰＩ選択画面４００に対するＡＰＩ機能の指定に応じて抽出されたＡＰＩ機能の組に含まれるＡＰＩ機能が、ＡＰＩ機能の適用順に従ってリスト表示される。ラジオボタン４０１１ａおよび４０１１ｂは、これらＡＰＩ機能表示領域４０１０ａおよび４０１０ｂに表示されるＡＰＩ機能の組から１つの組を排他的に指定する。

動作確認ツールは、決定ボタン４０１２が操作されると、ＡＰＩ機能表示領域４０１０ａおよび４０１０ｂに表示されるＡＰＩ機能の組のうち、ラジオボタン４０１１ａおよび４０１１ｂにより選択された組に含まれる各ＡＰＩ機能を、選択されたＡＰＩ機能として特定する。動作確認ツールは、選択されたＡＰＩ機能が特定されると、上述の図１３のフローチャートのステップＳ１０３以降の処理、または、図１９のフローチャートのステップＳ２０３以降の処理を実行する。

このように、第３の実施形態に係る動作確認ツールは、リクエストのスキーマに依存関係があるＡＰＩ機能の組を予め登録しておき、登録された組に対する利用者の選択に応じて、候補の組を利用者に提示するようにしている。そのため、利用者は、必要な処理を行うためのＡＰＩ機能を一々指定する必要が無く、ＡＰＩ機能の動作確認処理への負荷が軽減される。

なお、上述では、式（１）〜（４）に例示したように、リクエストのスキーマに依存関係のあるＡＰＩ機能の組を、全てのパターンについて作成しているが、これはこの例に限定されない。例えば、直前の依存関係のみに基づきＡＰＩ機能の組を作成してもよい。例えば、ＡＰＩ機能の組｛サービス認証、テナント認証｝の情報と、ＡＰＩ機能の組｛テナント認証、ｋｅｙ，ｖａｌｕｅ登録｝の情報とから、共通するＡＰＩ機能｛テナント認証｝に基づき、依存関係にあるＡＰＩ機能の組｛サービス登録、テナント認証、ｋｅｙ，ｖａｌｕｅ登録｝を導出することができる。

（第４の実施形態）
次に、第４の実施形態について説明する。第４の実施形態に係る動作確認ツールは、指定したＡＰＩ機能が依存関係にある、順序が当該ＡＰＩ機能の前のＡＰＩ機能を順次選択するようにしている。図２２（ａ）、図２２（ｂ）および図２２（ｃ）は、第４の実施形態に係るＡＰＩ選択画面の例を示す。

なお、第４の実施形態に係る動作確認ツールは、ＡＰＩ選択画面４１０を、例えば図１３のフローチャートにおけるステップＳ１００〜ステップＳ１０２、または、図１９のフローチャートにおけるステップＳ２００〜ステップＳ２０２の処理の代わりに生成し、利用者ＰＣ３１に表示させる。動作確認ツールは、ＡＰＩ選択画面４１０の生成に先立って、例えばＡＰＩ群２０から、利用可能なＡＰＩ機能のリストを取得する。

図２２（ａ）、図２２（ｂ）および図２２（ｃ）において、ＡＰＩ選択画面４１０ａ、４１０ｂおよび４１０ｃは、それぞれ選択領域４１００と、候補ボタン４１０２と、決定ボタン４１０３とが配置される。図２２（ａ）を例にとって、選択領域４１００は、例えば右端に表示される三角印をユーザ操作により指定することで、リスト表示４１０１ａのように、選択可能なＡＰＩ機能のリストが表示される。

動作確認ツールは、例えば利用者ＰＣ３１に対するユーザ操作により、リスト表示４１０１ａに対して目的とするＡＰＩ機能が指定され、候補ボタン４１０２が操作されると、指定されたＡＰＩ機能のスキーマ定義のキーを抽出する。そして、動作確認ツールは、利用可能な他のＡＰＩ機能のうち、スキーマ定義が抽出したキーと同じキーを含むＡＰＩ機能を特定する。

例えば、図２２（ａ）において指定されたＡＰＩ機能「ｋｅｙ，ｖａｌｕｅ登録ＡＰＩ」が、リクエストのスキーマにキーの値「ｃｏｏｋｉｅ」、「ｔｅｎａｎｔＩｄ」、「ｋｅｙ」および「ｖａｌｕｅ」を含む場合、動作確認ツールは、これらのキーの値をレスポンスの項目にキー値として持っているＡＰＩ機能のリストを作成する。

図２２（ｂ）は、このように作成されたリスト表示４１０１ｂが配置されたＡＰＩ選択画面４１０ｂの例を示す。ＡＰＩ選択画面４１０ｂにおいて、直前のＡＰＩ選択画面４１０ａで選択されたＡＰＩ機能の情報が領域４１１０に配置され、選択領域４１００に対してリスト表示４１０１ｂが配置されている。

この図２２（ｂ）のＡＰＩ選択画面４１０ｂにおいて、例えばＡＰＩ機能「テナント認証ＡＰＩ」が指定された場合、動作確認ツールは、指定されたＡＰＩ機能「テナント認証ＡＰＩ」が、リクエストのスキーマにキーの値「ｐａｓｓｗｏｒｄ」および「ｔｅｎａｎｔＩｄ」を含む場合、動作確認ツールは、これらのキーの値をレスポンスの項目にキー値として持っているＡＰＩ機能のリストを作成する。

図２２（ｃ）は、このように作成されたリスト表示４１０１ｃが配置されたＡＰＩ選択画面４１０ｃの例を示す。上述のＡＰＩ選択画面４１０ｂと同様に、ＡＰＩ選択画面４１０ｃにおいて、直前のＡＰＩ選択画面４１０ｂで選択されたＡＰＩ機能の情報が領域４１１０に配置され、選択領域４１００に対してリスト表示４１０１ｃが配置されている。

なお、動作確認ツールは、ＡＰＩ選択画面４１０ａ、４１０ｂおよび４１０ｃの何れの段階で決定ボタン４１０３が操作されても、動作確認処理を実行させることができる。この場合、決定ボタン４１０３が操作された時点で指定されているＡＰＩ機能について、動作確認処理が実行される。動作確認ツールは、決定ボタン４１０３が操作されると、上述の図１３のフローチャートのステップＳ１０３以降の処理、または、図１９のフローチャートのステップＳ２０３以降の処理を実行する。

このように、第４の実施形態に係る動作確認ツールは、指定したＡＰＩ機能が依存関係にある、順序が当該ＡＰＩ機能の前のＡＰＩ機能を順次選択するようにしているため、利用者は、必要な処理を行うためのＡＰＩ機能を容易に指定することができ、ＡＰＩ機能の動作確認処理への負荷が軽減される。

なお、上述の各実施形態は、本発明の好適な実施の例ではあるがこれに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変形による実施が可能である。

１ 情報処理システム
１０ Ｗｅｂサーバ
１１ Ｗｅｂアプリ
２０ ＡＰＩ群
３０ 提供者ＰＣ
３１ 利用者ＰＣ
４０ ネットワーク
１０１，１２１ ＣＰＵ
１０４，１２６ ストレージ
１２５ 表示装置
１２８ 入力デバイス
２００ プログラム
２０１ ＡＰＩ機能
２１０ リクエスト
２１３ レスポンス
３００ スキーマ情報
３１０，３２０，３３０ リクエストのスキーマ定義
３１１，３２１，３３１ レスポンスのスキーマ定義
３６０，４１０ａ，４１０ｂ，４１０ｃ ＡＰＩ選択画面
３６１ａ，３６１ｂ 動作確認画面
３７０ 結果情報
４００ 第１のＡＰＩ選択画面
４０１ 第２のＡＰＩ選択画面
１０００ 格納部
１００１ 操作部
１００２ 選択部
１００３ 取得部
１００４ 生成部
１００５ 実行制御部
１００６ 表示情報制御部
３６００₁，３６００₂，３６００₃，４０００，４１００ 選択領域
３６０１，４００１，４１０１ａ，４１０１ｂ，４１０１ｃ リスト表示
３６１０ａ₁，３６１０ａ₂，３６１０ａ₂’、３６１０ａ₃，３６１０ａ₃’ ＡＰＩ機能領域
３６１２ａ₁₁，３６１２ａ₂₁，３６１２ａ₂₁−１，３６１２ａ₂₁−２，３６１２ａ₂₂，３６１２ａ₂₂−１，３６１２ａ₂₂−２，３６２１ａ₃₁，３６２１ａ₃₁−１，３６２１ａ₃₁−２，３６１２ａ₃₂，３６１２ａ₃₂−１，３６１２ａ₃₂−２，３６１２ａ₃₃，３６１２ａ₃₄ 入力領域
３７００，３７００₁，３７００₂ リクエスト情報
３７０１，３７０１₁，３７０１₂ レスポンス情報
４００２，４１０２ 候補ボタン
４０１０ａ，４０１０ｂ ＡＰＩ機能表示領域
４０１１ａ，４０１１ｂ ラジオボタン

特開２０１２−０７３７７８号公報

Claims (9)

1. プログラムに実装されるプログラムインタフェースの少なくともリクエストおよびレスポンスを定義するスキーマ情報を格納する格納部と、
   前記プログラムインタフェースをユーザ操作に応じて選択し、選択されたプログラムインタフェースの順序を指定する選択部と、
   前記選択されたプログラムインタフェース毎に前記スキーマ情報を取得する取得部と、
   前記選択されたプログラムインタフェースに対するリクエストを設定するための設定部を、前記取得部により取得されたスキーマ情報に基づき生成する生成部と、
   前記選択されたプログラムインタフェースが実装されるプログラムを、該選択されたプログラムインタフェースに前記設定部で設定された前記リクエストを用いて、前記順序に従い実行させる実行制御部と
   を備え、
   前記生成部は、
   前記取得部で取得されたスキーマ情報に定義されるリクエストに、前記選択されたプログラムインタフェースのうち該リクエストが定義されるプログラムインタフェースよりも前記順序が前のプログラムインタフェースの前記レスポンスが含まれている場合に、該レスポンスをリクエストとして前記設定部に設定する
   情報処理システム。
2. 前記生成部は、
   前記選択されたプログラムインタフェースのうち、前記順序が最初のプログラムインタフェースの前記設定部に対して、ユーザ入力に従い前記リクエストを設定し、前記順序が最後のプログラムインタフェースの前記設定部に対して、ユーザ入力に従い前記レスポンスを設定する
   請求項１に記載の情報処理システム。
3. 前記生成部は、
   前記設定部に対する前記リクエストの設定をユーザ入力に従い行う
   請求項１に記載の情報処理システム。
4. 前記生成部は、
   前記設定部に対して、前記選択されたプログラムインタフェースのうち、前記順序が前のプログラムインタフェースの前記スキーマ情報に基づき前記ユーザ入力に従い選択された前記リクエストを設定する
   請求項３に記載の情報処理システム。
5. 前記選択部は、
   ユーザ操作に応じて、前記レスポンスを取得すべき１の前記プログラムインタフェースを選択し、選択されたプログラムインタフェースと関連付けて予め格納されたプログラムインタフェースをさらに選択する
   請求項１乃至請求項４の何れか１項に記載の情報処理システム。
6. 前記格納部は、さらに、
   前記リクエストおよび前記レスポンスのうち少なくとも一方が共通する前記スキーマ情報が定義されたプログラムインタフェースの組を示す情報を格納し、
   前記選択部は、
   前記格納部が格納する前記組を示す情報に基づき、前記組のうち、ユーザ操作に応じて選択されたプログラムインタフェースが含まれる組を選択する
   請求項５に記載の情報処理システム。
7. 前記選択部は、
   第１のユーザ操作に応じて選択された前記プログラムインタフェースの前記スキーマ情報に含まれるリクエストのうち少なくとも１のリクエストに対応するレスポンスが含まれる前記スキーマ情報に対応する前記プログラムインタフェースを選択し、
   選択した該プログラムインタフェースから第２のユーザ操作に応じて選択されたプログラムインタフェースの前記スキーマ情報に含まれるリクエストのうち少なくとも１のリクエストに対応するレスポンスが含まれる前記スキーマ情報に対応する前記プログラムインタフェースをさらに選択する
   請求項１に記載の情報処理システム。
8. プログラムに実装されるプログラムインタフェースの少なくともリクエストおよびレスポンスを定義するスキーマ情報を格納する格納部と、
   前記プログラムインタフェースをユーザ操作に応じて選択し、選択されたプログラムインタフェースの順序を指定する選択部と、
   前記選択されたプログラムインタフェース毎に前記スキーマ情報を取得する取得部と、
   前記選択されたプログラムインタフェースに対するリクエストを設定するための設定部を、前記取得部により取得されたスキーマ情報に基づき生成する生成部と、
   前記選択されたプログラムインタフェースが実装されるプログラムを、該選択されたプログラムインタフェースに前記設定部で設定された前記リクエストを用いて、前記順序に従い実行させる実行制御部と
   を備え、
   前記生成部は、
   前記取得部で取得されたスキーマ情報に定義されるリクエストに、前記選択されたプログラムインタフェースのうち該リクエストが定義されるプログラムインタフェースよりも前記順序が前のプログラムインタフェースの前記レスポンスが含まれている場合に、該レスポンスをリクエストとして前記設定部に設定する
   情報処理装置。
9. 情報処理方法をコンピュータに実行させるための情報処理プログラムであって、
   前記情報処理方法は、
   プログラムに実装されるプログラムインタフェースをユーザ操作に応じて選択し、選択されたプログラムインタフェースの順序を指定する選択ステップと、
   前記選択されたプログラムインタフェース毎に、前記プログラムインタフェースの少なくともリクエストおよびレスポンスを定義するスキーマ情報を取得する取得ステップと、
   前記選択されたプログラムインタフェースに対するリクエストを設定するための設定部を、前記取得ステップにより取得されたスキーマ情報に基づき生成する生成ステップと、
   前記選択されたプログラムインタフェースが実装されるプログラムを、該選択されたプログラムインタフェースに前記設定部で設定された前記リクエストを用いて、前記順序に従い実行させる実行制御ステップと
   を備え、
   前記生成ステップは、
   前記取得ステップにより取得されたスキーマ情報に定義されるリクエストに、前記選択されたプログラムインタフェースのうち該リクエストが定義されるプログラムインタフェースよりも前記順序が前のプログラムインタフェースの前記レスポンスが含まれている場合に、該レスポンスをリクエストとして前記設定部に設定する
   情報処理プログラム。