JP2016151885A - Ａｐｉ集約装置 - Google Patents

Abstract

【課題】より多くの利用者が効率良く利用可能なように、複数のＡＰＩをマッシュアップする。【解決手段】ＡＰＩ集約装置２４は、アプリ２５ａとグルメ検索機能２７ｂとの間に複数のＡＰＩ２８ｂ１〜２８ｂ３を介して接続されている。ＡＰＩ集約装置２４が、グルメ検索機能２７ｂに繋がる複数のＡＰＩ２８ｂ１〜２８ｂ３を組合せるマッシュアップを行う際に、ＡＰＩ２８ｂ１〜２８ｂ３がグルメ検索機能２７ｂに対して行うリクエスト情報及びレスポンス情報の送受信中継の実行回数を計数する。ＡＰＩ集約装置２４が、その計数された実行回数から、ＡＰＩ２８が独立で実行した独立実行回数と、ＡＰＩ２８が組合されて実行した組合せ実行回数を求める。ＡＰＩ集約装置２４が、独立実行回数が予め定められた閾値βより小さく、且つ組合せ実行回数が予め定められた閾値γより大きい条件に当て嵌まるＡＰＩ２８を、マッシュアップするようにした。【選択図】図２

Description

本発明は、複数のＡＰＩ(Application Programming Interface)を組合せて提供するＡＰＩ集約装置に関する。

近年、プログラムであるスクラッチで開発していたような機能、地図描画や認証等の共通機能が、情報インターフェイスであるＡＰＩという形で提供されてきている。ＡＰＩを活用したアプリケーション（以下、アプリと略すこともある）の開発では、複数のＡＰＩを組合せて（マッシュアップして）１つのＡＰＩに見せることで、早く、安く、多様な機能のアプリを開発することができ、様々な企業が自社機能を実現するＡＰＩに注目している。つまり、ソフトウェア開発において、ＡＰＩを活用したソフトウェア開発により、幾つかのＡＰＩを組合せて検証を含む開発期間の短縮、開発コストを削減することが実施されている。

マッシュアップは、所望の動作となるように複数のＡＰＩを順次実行するようにプログラミングを行う。また、非特許文献１に記載のように、他者がＷＥＢ(World Wide Web)サーバを通じて提供するソフトウェア機能を積極的に再利用することによりマッシュアップを行っている。

例えば、グルメ検索機能に繋がる３つのＡＰＩを、１つのＡＰＩに見せかけるマッシュアップを行ったとする。この場合、目的の食べ物を検索するために、本来３回のリクエストを行わねばならない所を、１回のリクエストを行えば、所望の食べ物を検索することができる。

「セキュアプログラミング講座−Ｗｅｂアプリケーション編−第８章マッシュアップ」、[online]、2013、ＩＰＡ独立行政法人、情報処理推進機構、［平成２７年１月２６日検索］、インターネット〈URL:https://www.ipa.go.jp/security/awareness/vendor/programmingv2/web.html〉

しかし、アプリケーション開発者に当たるＡＰＩ利用者（以下、利用者と略すこともある）が利用したい複数のＡＰＩをマッシュアップすることは、当人にとっては利便性が高いが、他者にとっては利便性が低いといった不都合が生じる。つまり、全ての利用者が効率良く利用可能なように複数のＡＰＩをマッシュアップすることができないという問題がある。

本発明は、このような背景に鑑みてなされたものであり、より多くの利用者が効率良く利用可能なように、複数のＡＰＩをマッシュアップすることができるＡＰＩ集約装置を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、所定の目的を少なくとも通信を行って実現するイネーブラに繋がるＡＰＩを複数組合せたアプリケーションが、所望の情報を取得するためのリクエスト情報を前記ＡＰＩを介して前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記ＡＰＩを介して前記アプリケーションへ返信する通信システムにおいて、前記アプリケーションと前記イネーブラとの間に少なくとも前記ＡＰＩを介して接続されたＡＰＩ集約装置であって、前記ＡＰＩが前記イネーブラに対して行う前記リクエスト情報及び前記レスポンス情報の送受信中継の実行回数を計数し、この計数された実行回数から、前記ＡＰＩが独立で実行した独立実行回数と、前記ＡＰＩが組合されて実行した組合せ実行回数を求め、前記独立実行回数が予め定められた第１回数より小さく、且つ前記組合せ実行回数が予め定められた第２回数より大きい条件に当て嵌まるＡＰＩを、マッシュアップするＡＰＩ処理機能部を備えることを特徴とするＡＰＩ集約装置である。

この構成によれば、ＡＰＩがイネーブラに対して行うリクエスト情報及びレスポンス情報の送受信中継の実行回数を計数し、この実行回数から、ＡＰＩ独立実行回数と、ＡＰＩ組合せ実行回数を求め、これら回数を、予め定められた第１及び第２回数と比較することでマッシュアップするようにした。ここで、ＡＰＩが独立に実行されることはマッシュアップするには不適切と判断できる。また、ＡＰＩが組合されて実行されることはマッシュアップに適していると判断できる。このことから、マッシュアップに、不適切なことを示す回数に応じて第１回数を設定し、適切なことを示す回数に応じて第２回数を設定すれば、マッシュアップに不適切なＡＰＩを排除し、適切なＡＰＩをマッシュアップすることが可能となる。従って、利用者の自己都合によりマッシュアップされることが無くなり、統計的に優位にマッシュアップすることが可能となる。このため、多くの利用者が効率良く利用可能なように、複数のＡＰＩをマッシュアップすることができる。

請求項２に係る発明は、前記ＡＰＩ処理機能部は、前記マッシュアップを行う際に、先行側の少なくとも１つのＡＰＩのレスポンス情報と、後続側の少なくとも１つのＡＰＩのリクエスト情報とを紐付けて、マッシュアップすることを特徴とする請求項１に記載のＡＰＩ集約装置である。

この構成によれば、ＡＰＩ処理機能部が上記のようにマッシュアップするようにしたので、マッシュアップされたＡＰＩの実行順序を規定することができる。また、最後に実行されるＡＰＩのリクエスト情報に含まれる必要なリクエスト項目の設定を、当該ＡＰＩの先行側の１又は複数のＡＰＩのレスポンス情報から取得して設定可能となる。このため、最終的に必要なレスポンス情報が得られるような、リクエスト項目を設定することができる。

請求項３に係る発明は、前記ＡＰＩ処理機能部は、前記アプリケーションが所望の前記レスポンス情報を取得するための前記リクエスト情報におけるリクエスト項目の数が少ないほどに粗くなり、多いほどに細かくなる粒度を判断し、この判断された粒度に対応するリクエスト項目を、前記マッシュアップされたＡＰＩに対応付けることを特徴とする請求項１又は２に記載のＡＰＩ集約装置である。

この構成によれば、ＡＰＩ処理機能部が上記のように粒度を判断するようにしたので、その粒度によって、マッシュアップされたＡＰＩで最終的に必要とされるレスポンス情報を取得するためのリクエスト項目の数が判断され、マッシュアップＡＰＩに対応付けられる。このため、マッシュアップＡＰＩに、最終的に必要なレスポンス情報が得られるリクエスト項目を設定することが可能となる。

請求項４に係る発明は、前記ＡＰＩ処理機能部は、前記リクエスト項目の数が、予め定められた数値よりも少ない場合は粒度が粗い、前記数値以上の場合は粒度が細かいと判断することを特徴とする請求項３に記載のＡＰＩ集約装置である。

この構成によれば、ＡＰＩ処理機能部の上記の判断によって、粒度の粗い、細かいの判断を、リクエスト項目の数と、統計的に得ることが可能な数値との比較により行うことができるので、適正に粒度を判断することができる。

請求項５に係る発明は、前記ＡＰＩ処理機能部は、前記ＡＰＩが前記イネーブラに対して行う前記送受信中継の実行時間を計測し、１つのイネーブラに繋がる複数のＡＰＩの個々の実行時間が、予め定められた時間より短ければ、前記複数のＡＰＩがマッシュアップされていると判断することを特徴とする請求項１〜４の何れか１項に記載のＡＰＩ集約装置である。

この構成によれば、ＡＰＩ処理機能部の上記の判断によって、１つのイネーブラに繋がる複数のＡＰＩの個々の実行時間が予め定められた時間よりも短い場合、各ＡＰＩは独立には実行されていないと判断できる。このことから、複数のＡＰＩがマッシュアップされているか否かを適正に判断することができる。

本発明によれば、より多くの利用者が効率良く利用可能なように、複数のＡＰＩをマッシュアップすることができるＡＰＩ集約装置を提供することができる。

本発明の実施形態に係るＡＰＩ集約装置を含む通信システムの構成を示すブロック図である。 本実施形態のＡＰＩ集約装置によるマッシュアップのための動作を説明するブロック図である。 本実施形態のＡＰＩ集約装置によるマッシュアップ後の動作を説明するブロック図である。 本実施形態のＡＰＩ集約装置の特徴構成を示すブロック図である。 （ａ）リクエスト情報の構成を示す図、（ｂ）レスポンス情報の構成を示す図である。 （ａ）リクエスト情報の具体例を示す図、（ｂ）レスポンス情報の具体例を示す図である。 （ａ）ＡＰＩ情報の具体例を示す図、（ｂ）計測情報の具体例を示す図である。 （ａ）分析情報の具体例を示す図、（ｂ）マッシュアップＡＰＩに対するＡＰＩ情報の具体例を示す図である。 本実施形態のＡＰＩ集約装置によるマッシュアップ及び互換変換の動作を説明するためのフローチャートである。 本実施形態のＡＰＩ集約装置によるマッシュアップ及び互換変換の動作を説明するための通信システムのブロック図である。

以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係るＡＰＩ集約装置を含む通信システムの構成を示すブロック図である。
図１に示す通信システム２０は、ＡＰＩ集約装置２４と、ｍ個のアプリケーション２５ａ〜２５ｍと、ｊ個のＡＰＩ２６ａ〜２６ｊと、ｎ個のイネーブラ２７ａ〜２７ｎと、ｐ個のＡＰＩ２８ａ〜２８ｐとを備えて構成されている。

ｊ個のＡＰＩ２６ａ〜２６ｊは、ＡＰＩ集約装置２４とｍ個のアプリケーション２５ａ〜２５ｍとの間に接続されており、ｍ個のアプリケーション２５ａ〜２５ｍとは個数が異なる。また、ｐ個のＡＰＩ２８ａ〜２８ｐは、ＡＰＩ集約装置２４とｎ個のイネーブラ２７ａ〜２７ｎとの間に接続されている。ｐ個のＡＰＩ２８ａ〜２８ｐは、ｎ個のイネーブラ２７ａ〜２７ｎよりも個数が多い。イネーブラ２７ｂに３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３が繋がっている。このように、１つのイネーブラ２７は、１つのＡＰＩのみならず、複数のＡＰＩを持つ場合がある。本実施形態では、１つのイネーブラ２７ｂは、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を持つものとする。但し、全ＡＰＩ２８ａ〜２８ｐは、全イネーブラ２７ａ〜２７ｎと同数でもよい。

各々のアプリケーション（アプリ）２５ａ〜２５ｍは、クラウド等に存在し、言い換えれば、インターネットのＷＥＢ(World Wide Web)上に存在し、インターネットに接続されている。例えば、スマートフォン（スマホ）やパーソナルコンピュータ等の端末機に、アプリ（例えば２５ａ）をインストールし、このクライアントのアプリ２５ａからインターネット上のアプリサーバ（図示せず）にアクセスする。アプリサーバにはプログラミングコードが書かれており、このコードの中にＡＰＩ集約装置２４のＡＰＩ２６ａ〜２６ｊを実行するというソースコードが書かれている。このソースコードを実行すると、インターネットを介してＡＰＩ集約装置２４まで信号が伝わり、ＡＰＩ２８ａ〜２８ｐにアクセスする。このアクセスが行われると、ＡＰＩ集約装置２４に繋がっている例えば位置情報取得機能としてのイネーブラ２７ａのＡＰＩ２８ａから、「位置情報」を取得し、これをアプリサーバを介してスマートフォンに返すといった仕組みになっている。

ＡＰＩ２８ａ〜２８ｐは、イネーブラ２７ａ〜２７ｎに対してリクエスト情報及びレスポンス情報を送受信中継（単に、送受信ともいう）する動作を実行する。

なお、後述において、アプリ（例えば２５ａ）からＡＰＩ集約装置２４を介してＡＰＩ（例えば２８ｂ１）にアクセスすると表現した場合、そのアクセスは、次に記載の定義を含むものとする。即ち、アクセスとは、ＡＰＩ集約装置２４を介して送信されてきたリクエスト情報を、ＡＰＩ２８ｂ１がイネーブラ２７ｂへ送信し、また、イネーブラ２７ｂがリクエスト情報に応じて返信したレスポンス情報を、ＡＰＩ２８ｂ１がＡＰＩ集約装置２４（又はアプリ２５ａ）へ返信する動作を実行することを含む動作をいう。

イネーブラ２７ａ〜２７ｎは、通信処理機能を備え、位置検索や必要情報等のユーザが所望する情報を提供する等、何らかの目的を果たすための機能を有する装置である。本実施形態では、例えば１つのイネーブラ２７が１つの機能を持つものとする。１つの機能とは、例えば位置情報取得機能、グルメ検索機能及びレコメンド機能等の何れか１つの機能である。

なお、１つのイネーブラ２７は、位置情報取得機能、グルメ検索機能、レコメンド機能の３つの機能を併せ持ったり、２つの機能を併せ持ったりできる。当然のことながら、３つを超える機能を持つ場合もある。

ＡＰＩ集約装置２４は、１つのイネーブラ（例えば２７ｂ）が複数のＡＰＩ（例えば２８ｂ１，２８ｂ２，２８ｂ３）を持つ場合に、アプリ（例えば２５ａ）からのリクエストに応じて、利用者が効率良く利用可能に複数のＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３をマッシュアップする処理を行う。このＡＰＩ集約装置２４は、ＡＰＩ処理機能部２１、開発者ポータル機能部２２及び保守運用機能部２３を備える。

マッシュアップする処理を、図２及び図３を参照して具体的に説明する。但し、本実施形態では、図２に示すように、イネーブラ２７ａ（図１参照）は位置情報取得機能２７ａであり、イネーブラ２７ｂはグルメ検索機能２７ｂ、イネーブラ２７ｃはレコメンド機能２７ｃであるとする。位置情報取得機能２７ａにＡＰＩ２８ａが繋がり、グルメ検索機能２７ｂに３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３が繋がり、レコメンド機能２７ｃにＡＰＩ２８ｃが繋がっている。また、各ＡＰＩ２８ａ〜２８ｃを組合せてアプリ２５ａが作成されているとする。なお、位置情報取得機能２７ａ、グルメ検索機能２７ｂ、レコメンド機能２７ｃを、単に、機能２７ａ、機能２７ｂ、機能２７ｃ、と称す場合もある。

まず、図２に示す構成において、アプリ２５ａがＡＰＩ２８ａを介して位置情報取得機能２７ａから位置情報を取得した後に、グルメ検索機能２７ｂからグルメに係る情報を取得する処理を行うとする。この場合、アプリ２５ａはリクエスト情報を、矢印Ｙ１ａで示すように、ＡＰＩ２６ｂを介してＡＰＩ集約装置２４へ送信し、更に、矢印Ｙ１ｂで示すように、ＡＰＩ２８ｂ１を介してグルメ検索機能２７ｂへ送信する。これによって、グルメ検索機能２７ｂから、そのリクエスト情報に応じたレスポンス情報が返信される。このリクエスト情報が矢印Ｙ１ｃ，Ｙ１ｄで示すように、ＡＰＩ２８ｂ１、ＡＰＩ集約装置２４及びＡＰＩ２６ｂを介してアプリ２５ａへ返信される。このリクエスト及びレスポンスの処理が、次に、矢印Ｙ２ａ，Ｙ２ｂ，Ｙ２ｃ，Ｙ２ｄで示すように行なわれ、その次に、矢印Ｙ３ａ，Ｙ３ｂ，Ｙ３ｃ，Ｙ３ｄで示すように行なわれる。これによって、アプリ２５ａが所望の情報をグルメ検索機能２７ｂから取得する。

ここで、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を、図３に示すように、１つのＡＰＩ２８ｂ３に見えるようにマッシュアップしたとする。この場合、アプリ２５ａは、矢印Ｙ４ａ，Ｙ４ｂ，Ｙ４ｃ，Ｙ４ｄで示すように、１回のリクエスト及びレスポンスの処理を行うのみで、所望の情報をグルメ検索機能２７ｂから取得するができる。
なお、この後、アプリ２５ａは、図２に示すＡＰＩ２８ｃを介してレコメンド機能２７ｃへアクセスして、ユーザが嗜好する飲食物情報等を取得する。

なお、図１に示すＡＰＩ処理機能部２１は、認証機能、トラフィック制御機能及びＩＦ変換機能を有する。
認証機能は、ＡＰＩがインターネットに公開され、様々なユーザに使用されるため、誰に使用されているかをユーザＩＤ等で認証する機能である。
トラフィック制御機能は、検索等のための通信が使用され、負荷が掛かり過ぎるとＡＰＩ集約装置２４等が故障するので、故障しないようにトラフィック制御を行う機能である。

ＩＦ機能は、アプリ２５ａ〜２５ｍからのリクエスト情報又はレスポンス情報の変換を行う機能である。この機能によれば、例えば、軽量なデータ記述言語の１つであるＪＳＯＮ(JavaScript（登録商標） Object Notation)形式を、構造化されたデータを交換するための言語であるＸＭＬ(Extensible Markup Language)形式に変換することができる。

開発者ポータル機能部２２は、ＡＰＩを利用するための窓口機能であり、アプリ開発者のアプリ開発支援（ＡＰＩドキュメントやＡＰＩ利用申請等）機能を有する。

保守運用機能部２３は、ＡＰＩ集約装置２４を保守する処理、実際にＡＰＩをＡＰＩ集約装置２４に接続する処理、実際にＡＰＩ互換処理が実行されているか否かを判定する処理等を行う。更に、保守運用機能部２３は、検索等のための通信のトラフィック量を分析するトラフィック分析機能や、ＡＰＩ集約装置２４からグルメ検索機能等のＡＰＩにリクエスト情報を送れるようにするエンジニアリング機能を有する。

次に、図４にＡＰＩ集約装置２４の特徴構成を示す。このＡＰＩ集約装置２４は、ＡＰＩ信号取得部２１ａと、ＡＰＩ情報蓄積部２１ｂと、計測部２１ｃと、分析部２１ｅと、ＡＰＩ計測情報蓄積部２１ｄと、ＡＰＩ信号送信部２１ｆと、ＡＰＩ粒度判断部２１ｇと、ＡＰＩ粒度変換部２１ｈと、情報作成部２１ｉと、開発者ポータル機能部２２とを備えて構成されている。

なお、ＡＰＩ信号取得部２１ａを取得部２１ａともいい、ＡＰＩ情報蓄積部２１ｂを蓄積部２１ｂ、ＡＰＩ計測情報蓄積部２１ｄを蓄積部２１ｄ、ＡＰＩ信号送信部２１ｆを送信部２１ｆ、ＡＰＩ粒度判断部２１ｇを粒度判断部２１ｇ、ＡＰＩ粒度変換部２１ｈを粒度変換部２１ｈともいう。

図４において、破線枠２１で囲む次の要素がＡＰＩ処理機能部２１（図１参照）の機能を分割した構成要素である。即ち、ＡＰＩ信号取得部２１ａ、ＡＰＩ情報蓄積部２１ｂ、計測部２１ｃ、分析部２１ｅ、ＡＰＩ計測情報蓄積部２１ｄ、ＡＰＩ信号送信部２１ｆ、ＡＰＩ粒度判断部２１ｇ、ＡＰＩ粒度変換部２１ｈ、情報作成部２１ｉが、ＡＰＩ処理機能部２１の構成要素である。

ここで、図４に示すＡＰＩ集約装置２４で用いられるリクエスト情報とレスポンス情報の構成を、図５を参照して説明する。
図５（ａ）に示すように、リクエスト情報ｑは、メソッド及びＵＲＩ（Uniform Resource Identifier）を有するリクエスト部ｑｒと、ヘッダ情報及び認証情報を有するヘッダ部ｑｈと、データ形式及びパラメータを有するボディ部ｑｂとから構成されている。

図５（ｂ）に示すように、レスポンス情報ｐは、ステータスコードを有するレスポンス部ｐｒと、ヘッダ情報を有するヘッダ部ｐｈと、データ形式及びパラメータを有するボディ部ｐｂとから構成されている。

次に、図６（ａ）及び（ｂ）に、リクエスト情報ｑとレスポンス情報ｐの構成例を示し、その説明を行う。
図６（ａ）に示すリクエスト情報ｑにおいて、リクエスト部ｑｒの情報は、例えば、「ＰＯＳＴ／ａｐｉＮａｍｅ／ｖ１／ｃａｌｌｓ」である。「ＰＯＳＴ」がメソッドであり、「ａｐｉＮａｍｅ／ｖ１／ｃａｌｌｓ」がＵＲＩである。
ヘッダ部ｑｈの情報は、例えば、「Ａｕｔｈｏｒｉｚａｔｉｏｎ ＡＰＩ−ＫＥＹ：ｈ４７ｔｑ３８４」である。「Ａｕｔｈｏｒｉｚａｔｉｏｎ」がヘッダ情報であり、「ＡＰＩ−ＫＥＹ：ｈ４７ｔｑ３８４」が認証情報である。

ボディ部ｑｂの情報は、例えば、「｛“ｎａｍｅ”：“Ａｌｉｃｅ” “ｆｒｏｍ”：”０４２２−５９−１１１１” “ｔｏ”：“０４２２−５９−２２２２”｝」である。｛｝内の全ての文字列がパラメータである。データ形式は、例えばＪＳＯＮ形式である。

次に、図６（ｂ）に示すレスポンス情報ｐにおいて、レスポンス部ｐｒの情報は、例えば、「２００ ＯＫ」であり、これがステータスコードである。
ヘッダ部ｐｈの情報は、例えば、「Ｌｏｃａｔｉｏｎ ｈｔｔｐ：／／ｘｘｘ／ａａａ／ｖ１／ｂｂ」であり、これがヘッダ情報である。

ボディ部ｐｂの情報は、例えば、「｛“ｉｄ”：“００１”｝」であり、これがパラメータである。データ形式は、例えばＪＳＯＮ形式である。

図４に戻って、アプリ２５ａは、事前に登録された宛先であるイネーブラ（例えば２７ｂとする）に繋がるＡＰＩ（宛先ＡＰＩ）２８ｂ１，２８ｂ２，２８ｂ３へ、矢印Ｙ１１で示す信号により、リクエスト情報を送信する。この送信されたリクエスト情報は、ＡＰＩ集約装置２４のＡＰＩ信号取得部２１ａで受信（取得）される。以降、イネーブラ２７ｂ及び、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を宛先ＡＰＩとして例に挙げて説明する。

ＡＰＩ信号取得部２１ａは、矢印Ｙ１２で示す信号により、取得したリクエスト情報を後述のＡＰＩ情報として蓄積部２１ｂへ出力すると共に、矢印Ｙ１３で示す信号により、同リクエスト情報を計測部２１ｃ及び分析部２１ｅを介して、宛先のイネーブラ２７ｂへ出力する。

宛先のイネーブラ２７ｂへのアクセスは、例えば、イネーブラ２７ｂに繋がる３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３（図２参照）がマッシュアップされている場合は、ＡＰＩ集約装置２４と、各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３との間で、リクエスト情報とレスポンス情報との遣り取りを複数回行うことができる。ＡＰＩ２８ｂ２，２８ｂ３の２つがマッシュアップされている場合は、ＡＰＩ２８ｂ１へアクセスし、次にＡＰＩ２８ｂ２，２８ｂ３へ纏めてアクセスすることが可能である。

蓄積部２１ｂは、ＡＰＩ情報を記憶して蓄積する。ＡＰＩ情報は、図７（ａ）に示すような、エリア情報取得ＡＰＩ２８ｂ１，カテゴリ情報取得ＡＰＩ２８ｂ２，グルメ検索ＡＰＩ２８ｂ３毎の、アプリＩＤ(identification)、ＡＰＩＩＤ、リクエストパラメータ及びレスポンスパラメータ等を含む情報である。なお、エリア情報取得ＡＰＩ２８ｂ１，カテゴリ情報取得ＡＰＩ２８ｂ２，グルメ検索ＡＰＩ２８ｂ３は、図２に示すＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３に対応している。

アプリＩＤは、アプリ２５ａ〜２５ｍ（図１参照）の固有情報である。ＡＰＩＩＤは、各機能２７ａ〜２７ｃに繋がるＡＰＩ２８ａ〜２８ｐ（図１参照）の固有情報である。リクエストパラメータは、アプリ２５ａによるリクエスト時における検索対象を検索するためのリクエスト項目としてのパラメータである。レスポンスパラメータは、リクエスト項目に応じて検索された情報であり、レスポンス情報に含まれる検索情報としてのパラメータである。

図４に戻って、計測部２１ｃは、リクエスト情報の宛先ＡＰＩ（例えば、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３）へのアクセス時に、宛先ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３の実行時間としてのＡＰＩ実行時間を計測し、更に、ＡＰＩ間実行時間、ＡＰＩ実行順序、ＡＰＩ実行順序実施回数、アプリ実行時間を計測する。これらを計測情報として、矢印Ｙ１４で示すようにＡＰＩ計測情報蓄積部２１ｄへ出力する。図７（ｂ）に計測情報であるＡＰＩ実行時間、ＡＰＩ間実行時間、ＡＰＩ実行順序、ＡＰＩ実行順序実施回数、アプリ実行時間の例を示す。

ＡＰＩ実行時間は、ＡＰＩの機能を実行している時間であり、例えば、グルメ検索ＡＰＩ２８ｂ３であれば、グルメに係るリクエストパラメータによる項目の情報を検索している時間である。図７（ｂ）の例では、ＡＰＩ２８ｂ１が０．１４ｍｓ、ＡＰＩ２８ｂ２が０．１６ｍｓ、ＡＰＩ２８ｂ３が３．０１ｍｓである。

ＡＰＩ間実行時間は、ＡＰＩから他のＡＰＩへの移行時間（ＡＰＩ間の移行時間）であり、例えば、エリア情報取得ＡＰＩ２８ｂ１からカテゴリ情報取得ＡＰＩ２８ｂ２へ移行する際に掛かる時間である。図７（ｂ）の例では、ＡＰＩ２８ｂ１からＡＰＩ２８ｂ２への移行時間が０．０３ｍｓ、ＡＰＩ２８ｂ２からＡＰＩ２８ｂ３への移行時間が０．１０ｍｓである。但し、ＡＰＩ間実行時間の閾値をαとして事前に設定し、ＡＰＩ２８ｂ２とＡＰＩ２８ｂ３のＡＰＩ間実行時間がαよりも小さければ、ＡＰＩ２８ｂ２とＡＰＩ２８ｂ３は組合されて（マッシュアップされて）実行されていると判断することが可能となる。なお、閾値αは、ＡＰＩ間の移行時間を多数回計測することにより統計的に得られる数値であってもよい。閾値αは、請求項記載の予め定められた時間である。

ＡＰＩ実行順序は、各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を実行する順序である。図７（ｂ）の例では、ＡＰＩ２８ｂ１、ＡＰＩ２８ｂ２、ＡＰＩ２８ｂ３の順序で移行するようになっている。

ＡＰＩ実行順序実施回数は、ＡＰＩ実行順序で各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３が実行した回数を示す。これは、全てのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３がその順序で実行した場合に、１回とカウントされる。
アプリ実行時間は、１つのアプリ２５ａの実行時間である。

分析部２１ｅは、計測部２１ｃで計測された計測情報を分析し、図８（ａ）に一例を示すＡＰＩ独立実行回数、ＡＰＩ組合せ実行回数、組合せＡＰＩの分析情報を生成し、この分析情報を図４に示す矢印Ｙ１５で示す信号により、ＡＰＩ計測情報蓄積部２１ｄに記憶して蓄積する。

但し、分析部２１ｅは、計測情報の分析量が膨大になると最新の分析結果を取得できなくなるため、事前に設定された計測情報の分析を閾値を用いて絞り込んでもよい。また、同一アプリからのリクエストの連続実行のみであれば分析しなくてもよい。更に、実行するアプリ数が少なくても、リクエストの実行回数が多い場合には、その実行回数を利用することで、スマホ等の端末機のＣＰＵ(Central Processing Unit)リソースの有効活用を図ることができる。なお、分析情報は、蓄積部２１ｂのＡＰＩ情報と共に、ポータル機能部２２で開発者がＡＰＩリストとして閲覧することが可能となっている。

上述したＡＰＩ独立実行回数は、各ＡＰＩ２８が独立して処理を実行した場合の回数である。このＡＰＩ独立実行回数は、各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３のＡＰＩ間実行時間｛図７（ｂ）｝が長ければ、各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３が独立して処理を実行したと判断して、各実行をカウントする。なお、ＡＰＩ独立実行回数は、信号中継時間が所定の閾値以上の場合は、インクリメントされるようにしてもよい。
図８（ａ）の例のように、ＡＰＩ２８ｂ１が１２回、ＡＰＩ２８ｂ２が１１回、ＡＰＩ２８ｂ３が０回の場合、ＡＰＩ２８ｂ１，２８ｂ２は独立で叩かれているが、ＡＰＩ２８ｂ３は０回なので独立では叩かれないことが分かる。このＡＰＩ２８ｂ３は、マッシュアップされていることが分かる。ここで、ＡＰＩ実行順序｛図７（ｂ）｝を見て、ＡＰＩ２８ｂ２の後にＡＰＩ２８ｂ３にアクセスされ、この際のＡＰＩ２８ｂ２とＡＰＩ２８ｂ３とのＡＰＩ間実行時間が短ければ、ＡＰＩ２８ｂ２とＡＰＩ２８ｂ３がマッシュアップされていることが分かる。

ＡＰＩ組合せ実行回数は、他の何れかのＡＰＩと組合されて処理を実行した際の回数を表す。図８（ａ）の例では、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３ともに、２２５回、２１０回、５６４回とＡＰＩ組合せ実行回数が非常に多いので、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３をマッシュアップしてもよいことが分かる。例えば、ＡＰＩ２８ｂ１は、異なるアプリケーション（２５ａ〜２５ｍの何れか１つ又は複数）から実行されたものを纏めてカウントしてもよい。
組合せＡＰＩは、自ＡＰＩに組合された他のＡＰＩ２８を表す情報である。

図４に示すイネーブラ２７ｂは、リクエスト情報に応じたレスポンス情報を、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３（図１参照）を介して、矢印Ｙ１６で示す信号により、送信部２１ｆへ送信する。

送信部２１ｆは、イネーブラ２７ｂからＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を介して送られて来るレスポンス情報を、矢印Ｙ１７で示す信号により、蓄積部２１ｂに保存すると共に、矢印Ｙ１８で示す信号により、アプリ２５ａへ送信する。

粒度判断部２１ｇは、矢印１９で示す信号により、蓄積部２１ｄに蓄積された分析情報を取得し、複数のＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３をマッシュアップ可能か否かの判断を行うと共に、マッシュアップ時等の適切なＡＰＩ粒度（後述）を判断するものである。この判断結果の情報は、矢印Ｙ２０で示す信号により、粒度変換部２１ｈへ出力される。

粒度判断部２１ｇは、ＡＰＩ独立実行回数が小さく、且つＡＰＩ組合せ実行回数が大きい条件に当て嵌まるＡＰＩ２８を、マッシュアップ可能と判断する。このため、粒度判断部２１ｇは、予めＡＰＩ独立実行回数の閾値をβ、ＡＰＩ組合せ実行回数の閾値をγとして持っており、蓄積部２１ｄから取得した分析情報のＡＰＩ独立実行回数が閾値βより小さく、ＡＰＩ組合せ実行回数の閾値γより大きい場合は、この条件に当て嵌まるＡＰＩがマッシュアップ可能と判断する。なお、閾値β又はγは、ＡＰＩ独立実行回数又はＡＰＩ組合せ実行回数を多数回計測することにより統計的に得られる数値であってもよい。閾値βは請求項記載の第１回数、閾値γは請求項記載の第２回数である。

次に、粒度判断部２１ｇは、リクエスト情報及びレスポンス情報からＡＰＩ粒度（単に、粒度ともいう）を判断する。ＡＰＩ粒度を判断する場合、次の３つがある。
１つ目は、マッシュアップするＡＰＩ２８の数から粒度を判断する。この場合、ＡＰＩ２８の数が予め定められた閾値未満であれば、粒度が粗いと判断し、閾値以上であれば粒度が細かいと判断する。

２つ目は、リクエスト情報及びレスポンス情報の各情報からＡＰＩ粒度を判断する。これは、図５（ａ）に示すリクエスト情報の場合、メソッドの個数、ヘッダ情報の個数、認証情報の個数の各々が、予め定められた閾値未満であれば、粒度が粗いと判断し、閾値以上であれば粒度が細かいと判断する。また、ＵＲＩの長さが、所定の閾値未満であれば、粒度が粗いと判断し、閾値以上であれば粒度が細かいと判断する。更に、データ形式の許容している形式が、所定の形式であれば、粒度が粗いと判断し、所定の形式で無ければ粒度が細かいと判断する。同様に、図５（ｂ）に示すレスポンス情報においても粒度を判断する。但し、レスポンス情報においては、図５（ｂ）の構成例では、リクエスト情報のメソッドの個数ではなく、ステータスコードの個数となり、また、リクエスト情報のＵＲＩ、認証情報が存在しない。

３つ目は、リクエスト情報及びレスポンス情報の各パラメータからＡＰＩ粒度を判断する。この場合は、図８（ｂ）に示すような、所望のレスポンスパラメータの数が得られるリクエストパラメータの数が、ＡＰＩ粒度となる。従って、リクエストパラメータ又はレスポンスパラメータの個数の各々が、予め定められた閾値ｋ未満であれば、粒度が粗いと判断し、閾値ｋ以上であれば粒度が細かいと判断する。なお、閾値ｋは、リクエストパラメータ又はレスポンスパラメータの個数を多数回取得することにより統計的に得られる数値であってもよい。閾値ｋは、請求項記載の予め定められた数値である。

図４に戻り、粒度変換部２１ｈは、複数のＡＰＩをマッシュアップしたり、ＡＰＩの粒度を粗く又は細かくする粒度変換を行うためのシナリオが記載されたシナリオ情報を保持している。なお、シナリオ情報には、粒度を変えないとするシナリオも記載されている。粒度変換部２１ｈは、そのシナリオ情報に従って、マッシュアップ及び粒度変換を行う。また、粒度変換は、粒度判断部２１ｇがマッシュアップ不可能と判断した場合でも、必要に応じて実施されるようになっている。

即ち、粒度変換部２１ｈは、粒度判断部２１ｇでマッシュアップ可能と判断された際に、シナリオ情報に従って、マッシュアップ対象の複数のＡＰＩをマッシュアップする。このマッシュアップされたＡＰＩを、マッシュアップＡＰＩという。この際に、粒度変換部２１ｈで粒度が粗いと判断されていれば、シナリオ情報に従って、マッシュアップＡＰＩの粒度としての例えばリクエストパラメータ数を少なくする。一方、粒度変換部２１ｈで粒度が細かいと判断されていれば、シナリオ情報に従って、リクエストパラメータ数を多くする。

つまり、粒度判断部２１ｇで、アプリ２５ａが所望のレスポンス情報を取得するためのリクエスト情報におけるリクエスト項目の数が少ないほどに粗くなり、多いほどに細かくなる粒度を判断し、粒度変換部２１ｈが、その判断された粒度に対応するリクエスト項目を、マッシュアップされたＡＰＩに対応付ける処理が行われる。

また、粒度変換部２１ｈは、シナリオ情報に従ってマッシュアップする場合、先行側のＡＰＩのレスポンス情報と、後続側のＡＰＩのリクエスト情報とを紐付けて、マッシュアップＡＰＩとする。なお、このマッシュアップ後も、マッシュアップする前のＡＰＩは、必要に応じてＡＰＩ集約装置２４を介して繋がるようにしてもよい。紐付けには、マッシュアップ対象の複数のＡＰＩのレスポンス情報とリクエスト情報とを１対１で紐付ける場合や、ｎ対１（又は１対ｎ）で紐付ける場合、ｎ対ｍ（又はｍ対ｎ）で紐付ける場合等、様々なパターンの紐付けが有る。このような紐付けも、シナリオ情報に記載されている。

例えばマッシュアップ対象の３つのＡＰＩがある場合、第１ＡＰＩのレスポンス情報と第３ＡＰＩのリクエスト情報とを１対１で紐付けるパターンがある。また、第１及び第２ＡＰＩの各レスポンス情報と、第３ＡＰＩのリクエスト情報とを２対１で紐付けるパターンがある。

粒度変換部２１ｈは、上述したマッシュアップＡＰＩ及びＡＰＩ粒度の情報に、ＡＰＩ識別情報としてのＡＰＩＩＤ等を付与してＡＰＩ情報を作成し、このＡＰＩ情報を矢印Ｙ２１で示す信号により、蓄積部２１ｂに蓄積する。

情報作成部２１ｉは、蓄積部２１ｂに蓄積されたマッシュアップＡＰＩやＡＰＩ粒度を含むＡＰＩ情報を矢印Ｙ２２で示す信号により取得し、更に、矢印Ｙ２３で示す信号により、ポータル機能部２２へ登録する。この登録されたＡＰＩ情報は、ＡＰＩドキュメントとしてのポータル機能部２２のＡＰＩリファレンス機能等に反映される。

アプリ開発者３０は、矢印Ｙ２４で示す信号により、ポータル機能部２２に登録されたＡＰＩドキュメントを閲覧してＡＰＩ粒度を選択し、マッシュアップＡＰＩを利用することができる。

＜実施形態の動作＞
次に、本実施形態に係るＡＰＩ集約装置２４によるマッシュアップ及びＡＰＩ粒度変換の動作を、図９に示すフローチャートと、図１０に示す通信システム２０Ａの構成図を参照して説明する。

但し、図１０に示すグルメ検索機能２７ｂに繋がる各ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３は、図７及び図８に示すエリア情報取得ＡＰＩ２８ｂ１，カテゴリ情報取得ＡＰＩ２８ｂ２，グルメ検索ＡＰＩ２８ｂ３に対応している。

図７（ａ）に示すように、エリア情報取得ＡＰＩ２８ｂ１及びカテゴリ情報取得ＡＰＩ２８ｂ２のリクエストパラメータは存在しない。このため、アプリ２５ａから各ＡＰＩ２８ｂ１，ＡＰＩ２８ｂ２には、パラメータを含まないリクエスト情報が送信されるようになっている。また、ＡＰＩ２８ｂ１のＡＰＩＩＤは［ａｐｉ−０００１］、ＡＰＩ２８ｂ２のＡＰＩＩＤは［ａｐｉ−０００２］、ＡＰＩ２８ｂ３のＡＰＩＩＤは［ａｐｉ−０００３］である。更に、アプリ２５ａのアプリＩＤは［ａｐｐ−０００１］である。

まず、図１０に、アプリ２５ａと各ＡＰＩ２６ａ〜２６ｅとの間の双方向矢印と、ＡＰＩ集約装置２４と各ＡＰＩ２８ｂ１〜２８ｂ３を介したグルメ検索機能２７ｂとの間の双方向矢印とで示すように、リクエスト情報とレスポンス情報とが送受信されているとする。この際、リクエスト情報及びレスポンス情報の送受信の順番は、図７（ｂ）のＡＰＩ実行順序に示すように、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３の順であるとする。

この場合、リクエスト情報に応じてＡＰＩ２８ｂ１から返信されるレスポンスパラメータは、図７（ａ）に示すように、「エリアコード」「エリア名称」「都道府県コード」「都道府県名」の４つであるとする。また、ＡＰＩ２８ｂ２から返信されるレスポンスパラメータは、「カテゴリーコード」「カテゴリー名」の２つであるとする。これらレスポンスパラメータは、ＡＰＩ集約装置２４の蓄積部２１ｂに保持される。

この保持されたレスポンスパラメータの内、「都道府県コード」と「カテゴリーコード」は、図７（ａ）に示すように、３番目のＡＰＩ２８ｂ３のリクエストパラメータとして、「ソート」「検索ワード」に横並びに付加されるようになっている。これは、上述したように、１番目と２番目のＡＰＩ２８ｂ１，２８ｂ２の各レスポンス情報が、３番目のＡＰＩ２８ｂ３のリクエスト情報に紐付けられていることによる。つまり、リクエストパラメータは、「都道府県コード」「カテゴリーコード」「ソート」「検索ワード」の４つである。

このような条件下において、図９に示すステップＳ１において、アプリ２５ａからリクエスト情報が宛先のＡＰＩ２８ｂ３及びグルメ検索機能２７ｂへ向けて送信されたとする。この際、リクエスト情報は、まず、ＡＰＩ２６ａを介してＡＰＩ集約装置２４へ送信される。

ステップＳ２において、リクエスト情報は、ＡＰＩ集約装置２４の取得部２１ａで取得され、図１０［１］で示すように蓄積部２１ｂに記憶される。また、リクエスト情報は、取得部２１ａから計測部２１ｃへ出力される。

ステップＳ３において、計測部２１ｃは、リクエスト情報の宛先ＡＰＩ（例えば、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３）へのアクセス時に、宛先ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３の実行時間としてのＡＰＩ実行時間を計測｛図１０［２］｝し、更に、ＡＰＩ間実行時間、ＡＰＩ実行順序、ＡＰＩ実行順序実施回数、アプリ実行時間を計測｛図１０［２］｝する。この計測された各時間等は、図７（ｂ）に示す通りである。

ステップＳ４において、計測部２１ｃは、その計測されたＡＰＩ実行時間、ＡＰＩ間実行時間、ＡＰＩ実行順序、ＡＰＩ実行順序実施回数、アプリ実行時間による計測情報を、図１０［３］で示すように蓄積部２１ｄに蓄積（保存）する。

ステップＳ５において、分析部２１ｅは、計測部２１ｃで計測された計測情報を分析｛図１０［４］｝し、図８（ａ）に一例を示すＡＰＩ独立実行回数、ＡＰＩ組合せ実行回数、組合せＡＰＩの分析情報を生成し、この分析情報を図１０［５］で示すように、蓄積部２１ｄに蓄積（保存）する。

次に、ステップＳ６において、粒度判断部２１ｇは、図１０［６］で示すように、蓄積部２１ｄに蓄積された分析情報を取得し、複数のＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３をマッシュアップ可能か否かの判断を行う。この判断は、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３のＡＰＩ独立実行回数が閾値β（例えば、２０回）より小さく、ＡＰＩ組合せ実行回数の閾値γ（例えば、１００回）より大きい条件に当て嵌まる場合にマッシュアップ可能と判断する。条件に当て嵌まらない場合は、マッシュアップ不可能と判断する。

この結果、マッシュアップ不可能（Ｎｏ）であれば、ステップＳ９おいて、マッシュアップ不可能なことを示す情報が、図１０［７］及び［８］で示すように、粒度変換部２１ｈを介して蓄積部２１ｂに蓄積される。

一方、上記ステップＳ６の判断結果、マッシュアップ可能（Ｙｅｓ）であれば、ステップＳ７において、粒度判断部２１ｇは、マッシュアップ時のＡＰＩ粒度が粗いか、細かいかを判断して何れかの情報を求める。その判断は、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３をマッシュアップした際に必要なリクエストパラメータの数（リクエスト項目の数）が、予め定められた閾値ｋ（例えば、「３」）よりも少ない場合は粒度が粗い、閾値ｋ以上の場合は粒度が細かいと判断する。

ここで、必要なレスポンスパラメータが図７（ａ）のＡＰＩ２８ｂ３の欄に示す「店舗名」「店舗ＵＲＬ」「住所」「電話番号」であるとすると、このパラメータを取得するために必要なリクエストパラメータは、「都道府県コード」「カテゴリーコード」「ソート」「検索ワード」の４つである。このリクエストパラメータは、３番目のＡＰＩ２８ｂ３のものであり、これは、上述したように、１番目と２番目のＡＰＩ２８ｂ１，２８ｂ２の各レスポンス情報が、３番目のＡＰＩ２８ｂ３のリクエスト情報に紐付けられることにより生成｛図１０［７］｝される。

即ち、１番目と２番目のＡＰＩ２８ｂ１，２８ｂ２のレスポンスパラメータの「都道府県コード」と「カテゴリーコード」が、３番目のＡＰＩ２８ｂ３のリクエストパラメータとして、「ソート」「検索ワード」に横並びに付加されることにより生成｛図１０［７］｝される。

このことから、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を１つにマッシュアップした際に必要なリクエストパラメータは、図８（ｂ）に示すように、所望のレスポンスパラメータ「店舗名」「店舗ＵＲＬ」「住所」「電話番号」を得るためのレスポンスパラメータの「ソート」「検索ワード」の２つである。この場合、上記ステップＳ７の判断では、閾値ｋ「３」よりも少ないので粒度が粗いと判断されて、粒度が粗いことを示す情報が得られる。なお、閾値ｋ「３」以上の場合は、粒度が細かいと判断されるが、ここでは粗いと判断されたとする。

次に、ステップＳ８において、粒度変換部２１ｈは、シナリオ情報に従ってマッシュアップ及び粒度変換を次のように行う。

即ち、粒度変換部２１ｈは、粒度判断部２１ｇでマッシュアップ可能と判断された際に、シナリオ情報に従って、マッシュアップ対象の３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を１つにマッシュアップする。これをマッシュアップＡＰＩとする。この際、粒度変換部２１ｈは、更にシナリオ情報に従って、ＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３の順に実行されるようにマッシュアップする。また、１番目と２番目のＡＰＩ２８ｂ１，２８ｂ２のレスポンス情報を、３番目のＡＰＩ２８ｂ３のリクエスト情報に紐付けて、マッシュアップＡＰＩとする。

更に、粒度変換部２１ｈは、粒度変換部２１ｈで粒度が粗いと求められているので、シナリオ情報に従って、マッシュアップＡＰＩの粗い粒度としての例えばリクエストパラメータ数を閾値ｋ「３」よりも少ない「ソート」「検索ワード」の２つとする。

次に、ステップＳ９において、粒度変換部２１ｈは、上記ステップＳ８で得たマッシュアップＡＰＩ及びＡＰＩ粒度の情報に、ＡＰＩ識別情報としてのＡＰＩＩＤ［ａｐｉ−０００１］［ａｐｉ−０００２］［ａｐｉ−０００３］を付与してＡＰＩ情報を作成する。このＡＰＩ情報を蓄積部２１ｂに蓄積｛図１０［８］｝する。

これによって、３つのＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３はマッシュアップされて、図３に示したように、１つのマッシュアップＡＰＩ２８ｂ３となる。この場合、アプリ２５ａから図８（ｂ）に示すリクエストパラメータ「ソート」「検索ワード」を、ＡＰＩ２６ｂ、ＡＰＩ集約装置２４を介してＡＰＩ２８ｂ３へ送信する。このＡＰＩ２８ｂ３に繋がるグルメ検索機能２７ｂがレスポンス情報として、図８（ｂ）に示すレスポンスパラメータ「店舗名」「店舗ＵＲＬ」「住所」「電話番号」を返信するので、アプリ２５ａは１回のレスポンス送信により、所望のレスポンス情報を得ることができる。

＜実施形態の効果＞
以上説明した本実施形態のＡＰＩ集約装置２４は、通信システム２０において、アプリケーションとグルメ検索機能２７ｂとの間に複数のＡＰＩ２８ｂ１，２８ｂ２，２８ｂ３を介して接続されている。通信システム２０は、所定の目的を少なくとも通信を行って実現する例えばグルメ検索機能２７ｂに繋がるＡＰＩを複数組合せたアプリケーション２５ａが、所望の情報を取得するためのリクエスト情報をＡＰＩを介してグルメ検索機能２７ｂへ送信する。この送信されたリクエスト情報を受信したグルメ検索機能２７ｂがリクエスト情報に応じたレスポンス情報を、ＡＰＩを介してアプリケーションへ返信する。

本実施形態の特徴は、ＡＰＩ集約装置２４のＡＰＩ処理機能部２１が、グルメ検索機能２７ｂに繋がる複数のＡＰＩ２８ｂ１〜２８ｂ３を組合せるマッシュアップを行う際に、ＡＰＩ２８ｂ１〜２８ｂ３がグルメ検索機能２７ｂに対して行うリクエスト情報及びレスポンス情報の送受信中継の実行回数を計数する。更に、ＡＰＩ集約装置２４が、その計数された実行回数から、ＡＰＩが独立で実行した独立実行回数と、ＡＰＩが組合されて実行した組合せ実行回数を求める。そして、ＡＰＩ集約装置２４が、独立実行回数が予め定められた第１回数としての閾値βより小さく、且つ組合せ実行回数が予め定められた第２回数としての閾値γより大きい条件に当て嵌まるＡＰＩを、マッシュアップするようにした。

これによって、ＡＰＩ２８ｂ１〜２８ｂ３がグルメ検索機能２７ｂに対して行うリクエスト情報及びレスポンス情報の送受信中継の実行回数を計数し、この実行回数から、ＡＰＩ独立実行回数と、ＡＰＩ組合せ実行回数を求め、これら回数を、予め定められた閾値β，γと比較することでマッシュアップすることを決定するようにした。予め設定した時間間隔で繰り返し判断をしてもよい。また、別に予め設定した時間間隔での閾値を用いてもよい。

ＡＰＩが独立に実行されることはマッシュアップするには不適切と判断できる。また、ＡＰＩが組合されて実行されることはマッシュアップに適していると判断できる。このことから、マッシュアップに、不適切なことを示す回数に応じて閾値βを設定し、適切なことを示す回数に応じて閾値γを設定すれば、マッシュアップに不適切なＡＰＩを排除し、適切なＡＰＩをマッシュアップすることが可能となる。従って、利用者の自己都合によりマッシュアップされることが無くなり、統計的に優位にマッシュアップすることが可能となる。このため、多くの利用者が効率良く利用可能なように、複数のＡＰＩ２８ｂ１〜２８ｂ３をマッシュアップすることができる。

また、ＡＰＩ処理機能部２１は、マッシュアップを行う際に、先行側の少なくとも１つのＡＰＩのレスポンス情報と、後続側の少なくとも１つのＡＰＩのリクエスト情報とを紐付けて、マッシュアップするようにした。

これによって、マッシュアップされたＡＰＩの実行順序を規定することができる。また、最後に実行されるＡＰＩのリクエスト情報に含まれる必要なリクエスト項目の設定を、当該ＡＰＩの先行側の１又は複数のＡＰＩのレスポンス情報から取得して設定可能となる。このため、最終的に必要なレスポンス情報が得られるような、リクエスト項目を設定することができる。

また、ＡＰＩ処理機能部２１は、アプリケーションが所望のレスポンス情報を取得するためのリクエスト情報におけるリクエスト項目の数が少ないほどに粗くなり、多いほどに細かくなる粒度を判断し、この判断された粒度に対応するリクエスト項目を、マッシュアップされたＡＰＩに対応付けるようにした。

これによれば、粒度によって、マッシュアップされたＡＰＩで最終的に必要とされるレスポンス情報を取得するためのリクエスト項目の数が判断され、マッシュアップＡＰＩに対応付けられる。このため、マッシュアップＡＰＩに、最終的に必要なレスポンス情報が得られるリクエスト項目を設定することが可能となる。

また、ＡＰＩ処理機能部２１は、リクエスト項目の数が、予め定められた数値よりも少ない場合は粒度が粗い、数値以上の場合は粒度が細かいと判断するようにした。

これによって、粒度の粗い、細かいの判断を、リクエスト項目の数と、統計的に得ることが可能な数値との比較により行うことができるので、適正に粒度を判断することができる。

また、ＡＰＩ処理機能部２１は、ＡＰＩがグルメ検索機能２７ｂに対して行う送受信中継の実行時間を計測し、１つのグルメ検索機能２７ｂに繋がる複数のＡＰＩ２８ｂ１〜２８ｂ３の個々の実行時間が、予め定められた時間より短ければ、複数のＡＰＩがマッシュアップされていると判断するようにした。

これによって、１つのグルメ検索機能２７ｂに繋がる複数のＡＰＩ２８ｂ１〜２８ｂ３の個々の実行時間が予め定められた例えば極短時間の時間よりも短い場合、各ＡＰＩ２８ｂ１〜２８ｂ３は独立には実行されていないと判断できる。このことから、複数のＡＰＩ２８ｂ１〜２８ｂ３がマッシュアップされているか否かを適正に判断することができる。

その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

２０ 通信システム
２１ ＡＰＩ処理機能部
２１ａ ＡＰＩ信号取得部
２１ｂ ＡＰＩ情報蓄積部
２１ｃ 計測部
２１ｅ 分析部
２１ｄ ＡＰＩ計測情報蓄積部
２１ｆ ＡＰＩ信号送信部
２１ｇ ＡＰＩ粒度判断部
２１ｈ ＡＰＩ粒度変換部
２１ｉ 情報作成部
２２ 開発者ポータル機能部
２３ 保守運用機能部
２４ ＡＰＩ集約装置
２５ａ〜２５ｍ アプリケーション
２６ａ〜２６ｊ，２８ａ〜２８ｐ ＡＰＩ
２７ａ〜２７ｎ イネーブラ
２７ａ 位置情報取得機能
２７ｂ グルメ検索機能
２７ｃ レコメンド機能

Claims (5)

1. 所定の目的を少なくとも通信を行って実現するイネーブラに繋がるＡＰＩを複数組合せたアプリケーションが、所望の情報を取得するためのリクエスト情報を前記ＡＰＩを介して前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記ＡＰＩを介して前記アプリケーションへ返信する通信システムにおいて、前記アプリケーションと前記イネーブラとの間に少なくとも前記ＡＰＩを介して接続されたＡＰＩ集約装置であって、
   前記ＡＰＩが前記イネーブラに対して行う前記リクエスト情報及び前記レスポンス情報の送受信中継の実行回数を計数し、この計数された実行回数から、前記ＡＰＩが独立で実行した独立実行回数と、前記ＡＰＩが組合されて実行した組合せ実行回数を求め、前記独立実行回数が予め定められた第１回数より小さく、且つ前記組合せ実行回数が予め定められた第２回数より大きい条件に当て嵌まるＡＰＩを、マッシュアップするＡＰＩ処理機能部
   を備えることを特徴とするＡＰＩ集約装置。
2. 前記ＡＰＩ処理機能部は、
   前記マッシュアップを行う際に、先行側の少なくとも１つのＡＰＩのレスポンス情報と、後続側の少なくとも１つのＡＰＩのリクエスト情報とを紐付けて、マッシュアップする
   ことを特徴とする請求項１に記載のＡＰＩ集約装置。
3. 前記ＡＰＩ処理機能部は、
   前記アプリケーションが所望の前記レスポンス情報を取得するための前記リクエスト情報におけるリクエスト項目の数が少ないほどに粗くなり、多いほどに細かくなる粒度を判断し、この判断された粒度に対応するリクエスト項目を、前記マッシュアップされたＡＰＩに対応付ける
   ことを特徴とする請求項１又は２に記載のＡＰＩ集約装置。
4. 前記ＡＰＩ処理機能部は、
   前記リクエスト項目の数が、予め定められた数値よりも少ない場合は粒度が粗い、前記数値以上の場合は粒度が細かいと判断する
   ことを特徴とする請求項３に記載のＡＰＩ集約装置。
5. 前記ＡＰＩ処理機能部は、
   前記ＡＰＩが前記イネーブラに対して行う前記送受信中継の実行時間を計測し、１つのイネーブラに繋がる複数のＡＰＩの個々の実行時間が、予め定められた時間より短ければ、前記複数のＡＰＩがマッシュアップされていると判断する
   ことを特徴とする請求項１〜４の何れか１項に記載のＡＰＩ集約装置。

Images