JP2016151881A - Ａｐｉ集約装置及びａｐｉ互換方法 - Google Patents

Abstract

【課題】複数組み合わせたＡＰＩの１つが機能不全となった場合でも、その機能不全のＡＰＩに係る機能の情報をアプリケーションに提供する。
【解決手段】ＡＰＩ集約装置２４は、通信システムのアプリケーション２５ａとイネーブラ２７ａ〜２７ｄとの間にＡＰＩ２６ａ，２８ａ〜２８ｄを介して接続される。ＡＰＩ集約装置２４は、アプリケーション２５ａから所望のイネーブラ２７ｂへＡＰＩ２６ｂ，２８ｂを介してリクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合、当該機能不全のイネーブラ２７ｂに予め対応付けられた対応イネーブラ２７ｃからのレスポンス情報を、当該対応イネーブラ２７ｃに繋がる対応ＡＰＩ２８ｃを介して当該アプリケーション２５ａへ返信するＡＰＩ互換処理を行う。
【選択図】図２

Description

本発明は、複数のＡＰＩ(Application Programming Interface)を集約したアプリケーションから、リクエストを受け付けたＡＰＩ又はイネーブラが機能不全の場合でも所望の情報をユーザに提供することが可能なＡＰＩ集約装置及びＡＰＩ互換方法に関する。

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

提供されるＡＰＩについては、利用状況をＡＰＩ提供者にフィードバックする等の代償として、無償で提供されることが多い。ＡＰＩはグーグル、アマゾン等のユーザへ製品を提供しているベンダが、無償で公開、提供している場合が多い。

例えば、図１４に示すように、位置情報取得機能１０に繋がるＡＰＩ１０ａと、グルメ検索機能１１に繋がるＡＰＩ１１ａと、レコメンド機能１２に繋がるＡＰＩ１２ａとが集約されているとする。この際に、ユーザが飲食店を検索する場合、スマートフォン（スマホと略すこともある）にアプリケーション１３をインストールし、そのアプリ１３からインターネットを介して各ＡＰＩ１０ａ〜１２ａにアクセスして所望のグルメ情報を取得することができる。

この場合、アプリ１３からリクエスト情報１４ｑがＡＰＩ１０ａを介して位置情報取得機能１０に送信され、位置情報取得機能１０がＡＰＩ１０ａを介して位置情報であるレスポンス情報１４ｐをアプリ１３へ返す。これにより、スマホに飲食店の位置が表示される。次に、ユーザが、アプリ１３でその位置の周辺にどの様な飲食店があるか検索する。この検索によるリクエスト情報１５ｑがＡＰＩ１１ａを介してグルメ検索機能１１に送信され、グルメ検索機能１１がＡＰＩ１１ａを介して「店」の情報であるレスポンス情報１５ｐをアプリ１３へ返す。これにより、スマホに飲食店の情報が表示される。

次に、ユーザが、アプリ１３で飲食店の中から嗜好する飲食物を検索する。この検索によるリクエスト情報１６ｑがＡＰＩ１２ａを介してレコメンド機能１２に送信され、レコメンド機能１２がＡＰＩ１２ａを介してユーザが嗜好する飲食物の情報を含むレスポンス情報１６ｐをアプリ１３へ返す。これにより、スマホにユーザが嗜好する飲食物が表示される。
この種の技術として非特許文献１に記載のものがある。

「セキュアプログラミング講座−Ｗｅｂアプリケーション編−第８章マッシュアップ」、[online]、Copyright 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）を有するリクエスト部ｑｒと、ヘッダ情報及び認証情報を有するヘッダ部ｑｈと、データ形式及びパラメータを有するボディ部ｑｂとから構成されている。

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

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

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

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

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

図３に戻って、ＤＢ２１ｆは、ＡＰＩ互換情報を記憶するものである。ＡＰＩ互換情報は、前述したように、複数のＡＰＩに繋がる機能に何らかの互換性がある場合に、その互換性を有するＡＰＩの対応関係を示す情報である。ＡＰＩ互換情報には、差分パラメータ、類似率等が有る。

差分パラメータについて説明する。例えば、一方のＡＰＩ２８ｂに係るリクエスト情報に、パラメータとして送信元の電話番号と送信先の電話番号が保持されており、他方のＡＰＩ２８ｃに係るリクエスト情報に、パラメータとして送信元の電話番号と送信先のＵＲＬ(Uniform Resource Locator)が保持されているとする。この場合、パラメータは共通であるが、電話番号とＵＲＬとに差分があるので、これを差分パラメータという。
類似率は、２つのＡＰＩ２８ｂ，２８ｃに係る各全体情報における類似した情報の比率である。例えば、類似率は、全体情報（例えば１００）から差分パラメータ等の差分（例えば２０）を減算した結果（８０）が、全体情報（１００）に占める割合である。

ポータル機能部２２は、ＤＢ２１ｆから、矢印Ｙ０で示す信号により、ＡＰＩ処理機能部２１により公開されているＡＰＩに互換性のあるＡＰＩ互換情報を取得し、このＡＰＩ互換情報に応じて各ＡＰＩを対応付けて登録する。

ここで、アプリ開発者３０は、図示せぬ通信端末機により、矢印Ｙ１で示す信号により、ＡＰＩ利用時に利用するＡＰＩと、これに対応付けられているＡＰＩとを、ポータル機能部２２から選択し、これらの選択したＡＰＩを、破線矢印Ｙ２で示す信号によりアプリ２５ａに関連付ける。

アプリ２５ａは、矢印Ｙ３で示す信号により、ＡＰＩ集約装置２４を介して、当該アプリ２５ａに関連付けられたＡＰＩ（例えば図１の２８ｂ）に向けてリクエスト情報を送信する。この送信されたリクエスト情報は、ＡＰＩ集約装置２４の信号受信部２１ａで受信される。

信号受信部２１ａは、矢印Ｙ４で示す信号により、受信したリクエスト情報を蓄積部２１ｂに記憶して蓄積する。また、信号受信部２１ａは、矢印Ｙ５で示す信号により、同リクエスト情報を信号送信部２１ｃへ出力する。

信号送信部２１ｃは、矢印Ｙ６で示す信号により、そのリクエスト情報をＡＰＩ２８ｂ（図１参照）を介してイネーブラ２７ｂへ送信する。
イネーブラ２７ｂは、受信したリクエスト情報に応じたレスポンス情報を、矢印Ｙ７で示す信号により、ＡＰＩ２８ｂ（図１参照）を介して信号受信部２１ａへ送信する。
信号受信部２１ａは、イネーブラ２７ｂから受信したレスポンス情報を、矢印Ｙ８で示す信号により、判断部２１ｄへ出力する。

判断部２１ｄは、信号受信部２１ａからレスポンス情報を受信すると、蓄積部２１ｂから矢印Ｙ９で示す信号により、受信したレスポンス情報に対応するリクエスト情報を取得する。更に、判断部２１ｄは、ＤＢ２１ｆから矢印Ｙ１０で示す信号により、ポータル機能部２２で先に取得され、矢印Ｙ３で示したリクエスト情報の送信契機となったＡＰＩ互換情報を取得する。

更に、判断部２１ｄは、上記の取得したリクエスト情報へのレスポンス情報の対応関係から、当該レスポンス情報の送信元のイネーブラ２７ｂが正常か、機能不全かを判断する。この機能不全とは、（１）レスポンス情報を受信せず、タイムアウトとなった場合、（２）レスポンス情報としてエラー情報が返ってきた場合、（３）所望以外のレスポンス情報が返ってきた場合等である。

判断部２１ｄの判断において、レスポンス情報の内容がリクエスト情報の内容に適合していれば、正常なので、この場合、レスポンス情報は、実行部２１ｅ及び信号変換部２１ｇを通過して信号送信部２１ｃから、ＡＰＩ２６ｂ（図１参照）を介してアプリ２５ａへ返信される。

一方、レスポンス情報の内容がリクエスト情報の内容と全く対応していなかったり、レスポンス情報の内容が、この送信元のイネーブラ２７ｂの機能不全を示す情報である場合、判断部２１ｄは、イネーブラ２７ｂが機能不全と判断する。

この機能不全と判断した判断部２１ｄは、先に取得したＡＰＩ互換情報によりＡＰＩ互換動作（互換動作ともいう）が可能か否かを判断する。つまり、レスポンス情報の送信元のイネーブラ２７ｂに、他のイネーブラが対応付けられているか否かを判断する。対応付けられていない場合、判断部２１ｄは互換動作が不可能と判断する。この場合、判断部２１ｄは、矢印Ｙ１１で示す信号により、実行部２１ｅへ互換動作不可能の情報を出力する。この情報を受けた実行部２１ｅは、エラー情報を、矢印Ｙ１２，Ｙ１３，Ｙ１４で示す信号により、実行部２１ｅ及び信号変換部２１ｇを介して信号送信部２１ｃから、ＡＰＩ２６ｂ（図１参照）を更に介してアプリ２５ａへ返信する。これにより、アプリ２５ａに係る例えばスマートフォンのユーザは、所望の検索内容が検索不能であることを認識できる。

一方、レスポンス情報の送信元のイネーブラ２７ｂに、他のイネーブラ（例えば２７ｃ）が対応付けられている場合、判断部２１ｄは互換動作が可能と判断する。この場合、判断部２１ｄは、矢印Ｙ１１で示す信号により、実行部２１ｅへ互換動作可能の情報を出力する。互換動作可能を受けた実行部２１ｅは、矢印Ｙ１２で示す信号により、機能不全のイネーブラ２７ｂ及びこれに対応付けられたイネーブラ２７ｃのＡＰＩ互換情報を信号変換部２１ｇへ出力する。

信号変換部２１ｇは、機能不全のイネーブラ２７ｂへＡＰＩ２８ｂを介して送信されたリクエスト情報を、対応イネーブラ２７ｃに繋がる対応ＡＰＩ２８ｃへのリクエスト情報に変換し、これを、矢印Ｙ１３で示す信号により、信号送信部２１ｃへ出力する。信号送信部２１ｃは、その対応ＡＰＩ２８ｃへのリクエスト情報を、矢印Ｙ１５で示す信号により、ＡＰＩ２８ｃ（図１参照）を介して対応イネーブラ２７ｃへ送信する。

対応イネーブラ２７ｃは、受信したリクエスト情報に応じたレスポンス情報を、矢印Ｙ１６で示す信号により信号受信部２１ａへ送信する。この信号受信部２１ａは、受信したレスポンス情報を、矢印Ｙ１７で示す信号により信号変換部２１ｇへ出力する。

信号変換部２１ｇは、対応イネーブラ２７ｃから受信したレスポンス情報を、機能不全のイネーブラ２７ｂから本来適性に出力されるレスポンス情報に整合するように変換し、この変換されたレスポンス情報を、矢印Ｙ１８で示す信号により、信号送信部２１ｃへ入力する。信号送信部２１ｃは、その入力されたレスポンス情報を、矢印Ｙ１４で示す信号により、ＡＰＩ２６ｂを介してアプリ２５ａへ送信する。

この際、アプリ２５ａへのレスポンス情報が、対応イネーブラ２７ｃ（又は対応ＡＰＩ２８ｃ）からの情報である内容を付してもよい。また、対応イネーブラ２７ｃ（又は対応ＡＰＩ２８ｃ）からの応答であるレスポンス情報が、アプリ２５ａの所望の応答になるようにレスポンス情報を変更して、アプリ２５ａへ返信してもよい。この場合、図４（ｂ）に示したレスポンス情報ｐのレスポンス部ｐｒ、ヘッダ部ｐｈ及びボディ部ｐｂの何れかの情報を変更することになる。例えば、図５（ｂ）に示すボディ部ｐｂでは、データ形式がＪＳＯＮ形式であるが、これをＸＭＬ形式に変換することができる。

なお、信号変換部２１ｇは、上述したように、対応イネーブラ２７ｃから受信したレスポンス情報を、本来適性に出力されるレスポンス情報に整合するように変換するが、この変換を行わず、その受信したレスポンス情報をアプリ２５ａへ送信するようにしてもよい。

このような構成の図３に示すＡＰＩ集約装置２４は、各機能部を、リクエスト情報に対する処理部と、レスポンス情報に対する処理部とを分けて構成してもよい。

次に、前述した互換動作のパターンについて説明する。互換動作のパターンは、図６及び図７に示すように、第１〜第４の４つのパターンがある。図６（ａ）に第１パターン、（ｂ）に第２パターン、図７（ａ）に第３パターン、（ｂ）に第４パターンを示す。但し、全てのパターンにおいて、イネーブラ２７ｂにイネーブラ２７ｃが対応付けられているとする。これにより、各イネーブラ２７ｂ，２７ｃに繋がるＡＰＩ２８ｂにＡＰＩ２８ｃが対応付けられ、また、アプリ２５ａ側のＡＰＩ２６ｂにＡＰＩ２６ｃが対応付けられている。

図６（ａ）及び（ｂ）に示す第１及び第２パターンは、互換動作として、×印で示す機能不全となったイネーブラ２７ｂに繋がるＡＰＩ２８ｂに代わりに、矢印ｑ３で示すように、アプリ２５ａ側の対応ＡＰＩ２６ｃにリクエストする場合のパターンである。

図６（ａ）に示す第１パターンは、アプリ２５ａから矢印ｑ１，ｑ２で示すように、ＡＰＩ２６ｂ、ＡＰＩ集約装置２４、ＡＰＩ２８ｂを介してイネーブラ２７ｂへリクエスト情報を送信したが、イネーブラ２７ｂが×印で示すように機能不全であり、この不全内容のレスポンス情報が、矢印ｐ１で示すようにＡＰＩ集約装置２４に返ってきた場合である。この場合、ＡＰＩ集約装置２４は、互換動作が可能か否かを判断し、可能な場合に、矢印ｑ３で示すように、アプリ２５ａ側のＡＰＩ２６ｃにリクエスト情報を送信する。

このリクエスト情報は、矢印ｑ４で示すように対応ＡＰＩ２８ｃを介して対応イネーブラ２７ｃへ送信される。これにより、対応イネーブラ２７ｃがそのリクエスト情報に応じたレスポンス情報を、矢印ｐ２で示すようにＡＰＩ集約装置２４へ送信する。ＡＰＩ集約装置２４は、対応イネーブラ２７ｃから受信したレスポンス情報を、機能不全のイネーブラ２７ｂから本来適性に出力されるレスポンス情報に整合するように変換し、この変換されたレスポンス情報を、矢印ｐ３，ｐ４で示すように、ＡＰＩ２６ｂを介してアプリ２５ａへ返信する。

図６（ｂ）に示す第２パターンにおいて、矢印ｑ１，ｑ２，ｐ１，ｑ３，ｑ４，ｐ２の順序で示す動作は、第１パターンと同様である。この後、矢印ｐ２で示す対応イネーブラ２７ｃからのレスポンス情報を受信したＡＰＩ集約装置２４は、対応イネーブラ２７ｃから受信したレスポンス情報を、機能不全のイネーブラ２７ｂから本来適性に出力されるレスポンス情報に整合するように変換し、この変換されたレスポンス情報を、矢印ｐ５で示すように、ＡＰＩ２６ｃを介してアプリ２５ａへ返信する。

図７（ａ）及び（ｂ）に示す第３及び第４パターンは、互換動作として、×印で示す機能不全となったイネーブラ２７ｂに繋がるＡＰＩ２８ｂに代わりに、矢印ｑ５で示すように、対応イネーブラ２７ｃ側の対応ＡＰＩ２８ｃにリクエストする場合のパターンである。

図７（ａ）に示す第３パターンにおいて、矢印ｑ１，ｑ２，ｐ１の順序で示す動作は、第１パターンと同様である。この後、矢印ｑ４で示すように、機能不全のイネーブラ２７ｂからの不全内容のレスポンス情報を受信したＡＰＩ集約装置２４は、互換動作が可能か否かを判断し、可能な場合に、矢印ｑ５で示すように、対応ＡＰＩ２８ｃを介して対応イネーブラ２７ｃへリクエスト情報を送信する。

このリクエスト情報は、矢印ｑ４で示すように対応ＡＰＩ２８ｃを介して対応イネーブラ２７ｃへ送信される。これにより、対応イネーブラ２７ｃがそのリクエスト情報に応じたレスポンス情報を、矢印ｐ２で示すようにＡＰＩ集約装置２４へ送信する。ＡＰＩ集約装置２４は、対応イネーブラ２７ｃから受信したレスポンス情報を、機能不全のイネーブラ２７ｂから本来適性に出力されるレスポンス情報に整合するように変換し、この変換されたレスポンス情報を、矢印ｐ３，ｐ４で示すように、ＡＰＩ２６ｂを介してアプリ２５ａへ返信する。これにより、アプリ２５ａに係る例えばスマートフォンのユーザは、所望の検索内容を確認することができる。

図７（ｂ）に示す第４パターンにおいて、矢印ｑ１，ｑ２，ｐ１，ｑ５，ｑ４，ｐ２の順序で示す動作は、第３パターンと同様である。この後、矢印ｐ２で示す対応イネーブラ２７ｃからのレスポンス情報を受信したＡＰＩ集約装置２４は、対応イネーブラ２７ｃから受信したレスポンス情報を、機能不全のイネーブラ２７ｂから本来適性に出力されるレスポンス情報に整合するように変換し、この変換されたレスポンス情報を、矢印ｐ５で示すように、ＡＰＩ２６ｃを介してアプリ２５ａへ返信する。

このような第１〜第４パターンの互換動作は、図３に示したＡＰＩ集約装置２４の判断部２１ｄが互換動作可能と判断した際に、実行部２１ｅを介して信号送信部２１ｃが行うようになっている。実質的には、信号送信部２１ｃに第１〜第４パターンの何れか１つの互換動作を行うためのプログラムや回路が予め形成されている。

＜実施形態の動作＞
次に、本実施形態に係るＡＰＩ集約装置２４による互換動作を説明する。但し、互換動作として上述した第２パターンの場合を代表して説明する。図８に第２パターンの構成図を示す。

また、図９に第２パターンの互換動作において送受信されるリクエスト情報ｑの具体例を示し、図１０にレスポンス情報ｐの具体例を示し、図１１（ａ）にリクエスト情報のパラメータ（リクエストパラメータ）の具体例を示し、図１１（ｂ）にレスポンス情報のパラメータ（レスポンスパラメータ）の具体例を示す。これらの図９〜図１１に示すリクエスト情報ｑ及びレスポンス情報ｐの具体例は、図４（ａ）及び（ｂ）に示したリクエスト情報ｑ及びレスポンス情報ｐの基本構成に対応している。

図９に示すリクエスト情報ｑは、当該リクエスト情報ｑのリクエスト項目（リクエスト形式）として、メソッド種別、ＵＲＩ形式、ヘッダ情報、認証情報、データ形式を記載している。図１０に示すレスポンス情報ｐは、当該レスポンス情報ｐのレスポンス項目（レスポンス形式）として、ステータスコード、ヘッダ情報、データ形式を記載している。

本互換動作を行うための互換性の例では、パラメータの互換性について説明する。但し、パラメータ以外にも互換性を保つことが可能である。ＡＰＩを集約する本実施形態のＡＰＩ集約装置２４（図８参照）では、受信したリクエスト情報ｑ及び、送信するレスポンス情報ｐ、送受信する信号の全てについて互換のための変換を可能とする機能を持つ。例えば、認証情報（具体例は図５参照）が異なる場合に、当該認証情報を統一すること、図１０に示すデータ形式を異なる形式に変換、例えばＪＳＯＮ形式をＸＭＬ形式に変換（又はＸＭＬ形式をＪＳＯＮ形式に変換）することが可能である。つまり、データ形式が異なっていても互換性を保つことができる。

図８に示すＡグルメ検索機能２７ｂとＢグルメ検索機能２７ｃとは、前述したように、異なる企業が提供する飲食店情報を特定する検索機能である。アプリ２５ａから各検索機能２７ｂ，２７ｃに、図１１（ａ）に示すリクエストパラメータとしての店舗名と、緯度及び経度とをリクエスト情報で与えると、図１１（ｂ）に示すレスポンスパラメータとしての住所、カテゴリ及びＵＲＬがレスポンス情報として返信されるようになっている。

図９のＵＲＩ形式に示すように、Ａグルメ検索機能２７ｂの送信先は、「ｈｔｔｐ：／／ａｐｉ．ｓａｍｐｌｅ．ｃｏｍ／ｇｏｕｒｍｅｔＡ／」となっている。これは、ＡＰＩを集約するＡＰＩ集約装置２４で該当のＡＰＩを公開するときに、「ｈｔｔｐ：／／ａｐｉ．ｓａｍｐｌｅ．ｃｏｍ／」というようにドメイン名を共通化してＡＰＩをリストとして公開しているためである。

図１１（ａ）及び（ｂ）に示すＡグルメ検索機能２７ｂ及びＢグルメ検索機能２７ｃの各々は、リクエスト情報ｑ及びレスポンス情報ｐの各々に含むパラメータの意味は全く同じで、名称が異なる場合を示している。例えば、店舗名を表すＡグルメ検索機能２７ｂでは「ｎａｍｅ」が、Ｂグルメ検索機能２７ｃでは「ＳｈｏｐＮａｍｅ」となっているが、全く同じ内容を表している。このため、その単語の比較対象リストを、ＡＰＩ互換情報ＤＢ２１ｆ（図３参照）に保持することで互換性を表すことができる。また、ＡＰＩ２６ｂ，２６ｃでは、異なるＡＰＩであっても同じ意味のパラメータは同じパラメータ名で設計している。

このような内容のリクエスト情報ｑ及びレスポンス情報ｐが用いられる場合において、本実施形態のＡＰＩ集約装置２４による第２パターンの場合の互換動作を、図１２及び図１３に示すフローチャートを参照して説明する。

但し、ユーザが図示せぬスマホで飲食店情報を検索するものとする。この際に、スマホに図８に示すアプリケーション２５ａをインストールし、そのアプリ２５ａからインターネットを介して各ＡＰＩ２８ａ〜２８ｄにアクセスして、各機能２７ａ〜２７ｄから所望の飲食店情報を取得するものとする。

図１２に示すステップＳ１において、アプリケーション２５ａが飲食店の位置情報取得のためのリクエスト情報ｑを、矢印ｑ１１で示す信号により、ＡＰＩ２６ａ、ＡＰＩ集約装置２４、ＡＰＩ２８ａを介して位置情報取得機能２７ａへ送信する。このリクエスト情報ｑを受信した位置情報取得機能２７ａは、リクエスト情報ｑに応じた位置情報のレスポンス情報ｐを、矢印ｐ１１で示す信号により、ＡＰＩ２８ａ、ＡＰＩ集約装置２４、ＡＰＩ２６ａを介してアプリ２５ａへ返信する。これにより、アプリ２５ａで飲食店の位置情報が取得される。

これにより、スマホに飲食店の位置が表示され、ユーザは、その位置の周辺にどの様な飲食店があるかを検索可能となる。ここでユーザが、スマホにおいて、その飲食店検索のための操作を行ったとすると、次のような動作が実行される。

ステップＳ２において、アプリ２５ａはＡＰＩ集約装置２４に対して、Ａグルメ検索機能２７ｂのＡＰＩ２６ｂ「例えば図９に示すｈｔｔｐ：／／ａｐｉ．ｓａｍｐｌｅ．ｃｏｍ／ｇｏｕｒｍｅｔＡ」に、次の文字列のリクエスト情報ｑ（矢印ｑ１２）を送信する。
このリクエスト情報ｑは、例えば「ＧＥＴ ｈｔｔｐ：／／ａｐｉ．ｓａｍｐｌｅ．ｃｏｍ／ｇｏｕｒｍｅｔＡ？ｎａｍｅ＝ｘｘｘ＆ｌａｔｉｔｕｄｅ＝３６．１２４＆ｌｏｎｇｉｔｕｄｅ＝１３６．２２４」である。
このリクエスト情報ｑは、ＡＰＩ集約装置２４の蓄積部２１ｂ（図３）に一旦記憶（蓄積）される。

次に、ステップＳ３において、ＡＰＩ集約装置２４は、上記ステップＳ２で受信したリクエスト情報ｑを、矢印ｑ１３で示す信号により、ＡＰＩ２８ｂ「例えば図９に示すｈｔｔｐ：／／ｓｈｏｐＡ．ｘｓａｍｐｌｅ．ｃｏｍ／ｓｅａｒｃｈＧｏｕｒｍｅｔＡ」を介してＡグルメ検索機能２７ｂへ送信する。

この送信されるリクエスト情報ｑは、例えば「ＧＥＴ ｈｔｔｐ：／／ｓｈｏｐＡ．ｘｓａｍｐｌｅ．ｃｏｍ／ｓｅａｒｃｈＧｏｕｒｍｅｔＡ？ｎａｍｅ＝ｘｘｘ＆ｌａｔｉｔｕｄｅ＝３６．１２４＆ｌｏｎｇｉｔｕｄｅ＝１３６．２２４」である。

ステップＳ４において、Ａグルメ検索機能２７ｂは、受信したリクエスト情報ｑに応じたレスポンス情報ｐを、矢印ｐ１３で示す信号により、ＡＰＩ２８ｂを介してＡＰＩ集約装置２４へ返信する。

ここで、ステップＳ５において、ＡＰＩ集約装置２４は、上記ステップＳ４で受信されたレスポンス情報ｐが、タイムアウトとならず適正に受信されたか否かを判断する。この結果、適正に受信された場合（Ｙｅｓ）、ステップＳ６において、ＡＰＩ集約装置２４は、レスポンス情報ｐにエラー情報が無いか否かを判断する。この結果、エラー情報が無ければ（Ｙｅｓ）、ステップＳ７において、ＡＰＩ集約装置２４は、上記ステップＳ３で記憶したリクエスト情報を蓄積部２１ｂから取得する。

ステップＳ８において、ＡＰＩ集約装置２４は、上記ステップＳ５で受信されたレスポンス情報ｐが、上記ステップＳ７で取得されたリクエスト情報ｑの内容に適合しており、所望のレスポンス情報ｐか否かを判断する。この結果、所望のレスポンス情報ｐであれば（Ｙｅｓ）、ステップＳ９に進む。

ステップＳ９において、ＡＰＩ集約装置２４は、所望のレスポンス情報ｐがＡＰＩ２８ｂに係る対応ＡＰＩ（又は対応機能）２８ｃからのレスポンス情報が否かを判断する。この結果が、対応ＡＰＩ（又は対応機能）からのレスポンス情報で無ければ（Ｎｏ）、ステップＳ１０において、ＡＰＩ集約装置２４は、レスポンス情報をＡＰＩ２６ｂを介してアプリ２５ａへ返信（図８には矢印で示さず）する。これにより、アプリ２５ａに係るスマートフォンのユーザは、所望の検索内容を確認することができる。

一方、上記ステップＳ５において、タイムアウトとなりレスポンス情報ｐが受信されなかったと判断（Ｎｏ）された場合、上記ステップＳ６において、レスポンス情報ｐにエラー情報があると判断（Ｎｏ）された場合、上記ステップＳ８において、レスポンス情報ｐが所望のレスポンス情報でないと判断（Ｎｏ）された場合の、何れかの場合は、図１３に示すステップＳ１１へ進む。但し、それらステップＳ５，Ｓ６，Ｓ８の何れかの判断が（Ｎｏ）の場合は、Ａグルメ検索機能２７ｂが機能不全の場合である。

ステップＳ１１において、ＡＰＩ集約装置２４は、レスポンス情報ｐを受信したＡグルメ検索機能２７ｂに繋がるＡＰＩ２８ｂのＡＰＩ互換情報を、ＤＢ２１ｆから検索して取得する。

ステップＳ１２において、ＡＰＩ集約装置２４は、その取得したＡＰＩ互換情報により、Ａグルメ検索機能２７ｂの互換動作が可能か否かを判断する。この結果、不可能（Ｎｏ）と判断された場合、ステップＳ１３において、ＡＰＩ集約装置２４は、レスポンス情報ｐとしてエラー情報をアプリ２５ａへ返信（図８には矢印で示さず）する。これにより、アプリ２５ａに係るスマートフォンのユーザは、所望の検索内容が検索不能であることを認識できる。

一方、上記ステップＳ１２において、互換動作が可能（Ｙｅｓ）と判断された場合、ステップＳ１４において、ＡＰＩ集約装置２４は、図８に示すＡグルメ検索機能２７ｂへＡＰＩ２６ｂ，２８ｂを介して送信されたリクエスト情報ｑ１２を、Ａグルメ検索機能２７ｂに対応付けられたＢグルメ検索機能２７ｃに繋がる対応ＡＰＩ２６ｃへのリクエスト情報ｑｃに変換する。

この変換されたリクエスト情報ｑｃは、ステップＳ１５において、図８に矢印ｑ１４で示す信号により対応ＡＰＩ２６ｃへ送信され、更に、ＡＰＩ集約装置２４から矢印ｑ１５で示す信号により、ＡＰＩ２８ｃを介してＢグルメ検索機能２７ｃへ送信される。

但し、上記の矢印ｑ１４で示すリクエスト情報ｑｃは、例えば図９に示すＢグルメ検索機能２７ｃのＡＰＩ２６ｃのＵＲＩ形式の「ＧＥＴ ｈｔｔｐ：／／ａｐｉ．ｓａｍｐｌｅ．ｃｏｍ／ｇｏｕｒｍｅｔＢ？ｓｈｏｐ＝ｘｘｘ＆ｌａｔ＝３６．１２４＆ｌｏｎｇ＝１３６．２２４」である。

また、矢印ｑ１５で示すリクエスト情報ｑｃは、例えば図９に示すＢグルメ検索機能２７ｃのＡＰＩ２８ｃのＵＲＩ形式の「ＧＥＴ ｈｔｔｐ：／／ｓｈｏｐＢ．ｙｓａｍｐｌｅ．ｃｏｍ／ｓｈｏｐＳｅａｒｃｈＢ？ＳｈｏｐＮａｍｅ＝ｘｘｘ＆Ｌａｔｔｉｔｕｄｅ＝３６．１２４＆Ｌｏｎｇｉｔｕｄｅ＝１３６．２２４」である。

Ｂグルメ検索機能２７ｃは、図１２に示すステップＳ４において、受信したリクエスト情報ｑｃに応じたレスポンス情報ｐｃを、矢印ｐ１４で示す信号により、ＡＰＩ２８ｃを介してＡＰＩ集約装置２４へ返信する。

上記の矢印ｐ１４で示すレスポンス情報ｐｃは、例えば「ＳｈｏｐＡｄｄｒｅｓｓ：住所、ＧｅｎｒｅＮａｍｅ：お店ジャンル、ＳｈｏｐＵｒｌ：店舗ＵＲＬ」である。

次に、上述したステップＳ５，Ｓ６，Ｓ８の判断結果がＮｏであれば、ステップＳ１１へ進み、以降上述した処理が同様に行われる。この際、図１３のステップＳ１１，Ｓ１２と進み、ステップＳ１２においてＢグルメ検索機能２７ｃの次のグルメ検索機能が無いので、Ｎｏと判定され、ステップＳ１３においてエラー情報がアプリ２５ａへ送信されて処理が終了する。

一方、ステップＳ５，Ｓ６，Ｓ８の判断結果がＹｅｓであれば、ステップＳ９において、ＡＰＩ集約装置２４は、受信したレスポンス情報ｐｃが対応ＡＰＩ（又は対応機能）からのレスポンス情報が否かを判断する。この結果が、対応ＡＰＩ（又は対応機能）としてのＡＰＩ２８ｃを介したＢグルメ検索機能２７ｃからのレスポンス情報ｐｃで有れば（Ｙｅｓ）、ステップＳ１６に進む。

ステップＳ１６において、ＡＰＩ集約装置２４は、レスポンス情報ｐｃを、機能不全のＡグルメ検索機能２７ｂから本来適性に出力されるレスポンス情報ｐｂ１に整合するように変換する。
この変換されたレスポンス情報ｐｂ１は、例えば「ａｄｄｒｅｓｓ：住所、ｃａｔｅｇｏｒｙ：お店ジャンル、ｕｒｌ：店舗ＵＲＬ」となる。

そして、ステップＳ１０において、ＡＰＩ集約装置２４は、その変換したレスポンス情報ｐｂ１を、図８の矢印ｐ１５で示す信号により、ＡＰＩ２６ｃを介してアプリ２５ａへ送信する。これにより、アプリ２５ａに係るスマートフォンのユーザは、所望の検索内容を確認することができる。

なお、ユーザが、スマホのアプリ１３で検索した飲食店から、更に、嗜好する飲食物を検索したとする。この場合、その検索によるリクエスト情報ｑｄが、矢印ｑ１６で示す信号により、ＡＰＩ２６ｄ、ＡＰＩ集約装置２４、ＡＰＩ２８ｄを介してレコメンド機能２７ｄへ送信される。レコメンド機能２７ｄは、ユーザが嗜好する飲食物の情報であるレスポンス情報ｐｄを、矢印ｐ１６で示す信号により、ＡＰＩ２８ｄ、ＡＰＩ集約装置２４、ＡＰＩ２６ｄを介してアプリ２５ａへ返信する。これにより、アプリ２５ａでユーザが嗜好する飲食物の情報が取得されて表示される。

＜実施形態の効果＞
以上説明した本実施形態のＡＰＩ集約装置２４は、図２に示す通信システムのアプリケーション２５ａとイネーブラ２７ａ〜２７ｄとの間に少なくともＡＰＩ２６ａ，２８ａ〜２８ｄを介して接続されている。通信システムは、所定の目的を少なくとも通信を行って実現するイネーブラ２７ａ〜２７ｄに繋がるＡＰＩ２８ａ〜２８ｄを複数組み合わせたアプリケーション２５ａを有する。このアプリケーション２５ａが、所望の情報を取得するためのリクエスト情報を、情報インターフェイスであるＡＰＩ２６ａ，２８ａ〜２８ｄを介してイネーブラ２７へ送信する。この送信したリクエスト情報を受信したイネーブラ２７ａ〜２７ｄが当該リクエスト情報に応じたレスポンス情報を、ＡＰＩ２８ａ〜２８ｄ，２６ａを介してアプリケーション２５ａへ返信するようになっている。但し、「少なくともＡＰＩＡＰＩ２６ａ，２８ａ〜２８ｄを介して」というのは、アプリケーション２５ａからＡＰＩ集約装置２４に繋がるＡＰＩ２６ａとイネーブラ２７ａ〜２７ｄに繋がるＡＰＩ２８ａ〜２８ｄとは、ＡＰＩ集約装置２４を介する際にＡＰＩ２８ａ〜２８ｄのパラメータ等の形式が置き換えられている場合がある。形式を置き換える場合は、置き換える形式の対応関係をＡＰＩ集約装置２４で保持する。

本実施形態の特徴は、アプリケーション２５ａから所望のイネーブラ２７ｂへＡＰＩ２６ｂ，２８ｂを介してリクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合、当該機能不全のイネーブラ２７ｂに予め対応付けられた対応イネーブラ２７ｃからのレスポンス情報を、当該対応イネーブラ２７ｃに繋がる対応ＡＰＩ２８ｃを介して当該アプリケーション２５ａへ返信するＡＰＩ処理機能部２１を備えることにある。

これによって、複数組み合わせたＡＰＩ２８ａ〜２８ｄの何れかが機能不全となった場合でも、その機能不全の例えばＡＰＩ２８ｂに係る機能の情報を、そのＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃを介してアプリケーション２５ａに提供することができる。

ＡＰＩ処理機能部２１は、ＤＢ２１ｆと、判断部２１ｄ、変換部としての信号変換部２１ｇと、送信部としての信号送信部２１ｃとを備える構成とした。
ＤＢ２１ｆは、ＡＰＩ毎に繋がる機能に何らかの互換性が有る場合に、その互換性の有るＡＰＩ２８ｂ，２８ｃの対応関係を示すＡＰＩ互換情報を記憶する。

判断部２１ｄは、アプリケーション２５ａから送信されるリクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報を受信した際に、当該受信レスポンス情報が予め定められた規定の内容に不適合の場合、又は、当該受信レスポンス情報が当該リクエスト情報の内容に不適合の場合、当該不適合のレスポンス情報を返信したイネーブラ２７ｂに繋がるＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃが、ＤＢ２１ｆのＡＰＩ互換情報に存在すれば、互換動作可能と判断する。

信号変換部２１ｇは、判断部２１ｄで互換動作可能と判断された際に、不適合のレスポンス情報を返信したイネーブラ２７ｂへの送信リクエスト情報を、対応ＡＰＩ２８ｃに繋がる対応イネーブラ２７ｃへのリクエスト情報に変換し、この変換されたリクエスト情報を対応イネーブラ２７ｃへ送信する。
信号送信部２１ｃは、変換されたリクエスト情報を受信した対応イネーブラ２７から返信されるレスポンス情報を、アプリケーション２５ａへ返信する。

この構成によれば、ＡＰＩ２８ｂやイネーブラ２７ｂ等が機能不全となった場合でも、ＡＰＩ処理機能部２１が機能不全となったＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃ及び対応イネーブラ２７ｃへ切り替える互換切替動作を行って、対応イネーブラ２７ｃへの適合リクエスト情報を対応ＡＰＩ２８ｃを介して対応イネーブラ２７ｃへ送信し、これにより対応イネーブラ２７ｃから返信されるレスポンス情報をアプリケーション２５ａへ返信する。このため、アプリケーション２５ａを有するスマートフォン等の端末機において、所望のレスポンス情報を得ることができる。但し、ＡＰＩ集約装置２４に接続するイネーブラ２７ｃに繋がるＡＰＩ２８ｃが、接続される前からＡＰＩ集約装置２４へ繋がるＡＰＩ２８ｂのＡＰＩポリシーと合致しない場合には、ＡＰＩ集約装置２４でＡＰＩ２８ｃのパラメータ等の形式を置き換えている場合がある。そこで、その形式を置き換える場合は、置き換える形式の対応関係をＡＰＩ集約装置２４で保持する。

また、この構成の場合、後述するような、対応ＡＰＩ２８ｃのレスポンス情報を、元のＡＰＩ２８ｂのレスポンス情報に合った形への変換処理を行わない。このため、実行速度のオーバーヘッドがかからないというメリットがある。レスポンス情報は、ＡＰＩ集約装置２４で提供しているＡＰＩ２８ｃからレスポンスが返るため、互換性を考慮したＡＰＩ設計をＡＰＩ集約装置２４で行うことで、レスポンス時の変換処理や互換動作を意識したアプリ開発を考慮せず互換動作を行うことができる。

更に、この構成の場合、対応ＡＰＩ２８ｃを実行する際は、ＡＰＩ集約装置２４からＡＰＩ２８ｃにリクエストを送る。このため、ＡＰＩ集約装置２４から提供するＡＰＩの設計ポリシーを、リクエスト情報（メソッド・パラメータ等）に対する互換性を考慮した設計にしておく。この設計により、互換動作を行う際にリクエスト情報の複雑な変換処理をしなくても軽微の変更（リクエスト情報の宛先の変更等）で再送すればよいため、互換動作による実行速度のオーバーヘッドの削減を行うことが可能となる。また、互換動作のための変換処理をＡＰＩ集約装置２４にて新規に実装する際に開発コストを削減することができる。

次に、ＡＰＩ処理機能部２１は、アプリケーション２５ａから送信されたリクエスト情報を蓄積する蓄積部２１ｂを更に備える。この際に、判断部２１ｄは、蓄積されたと同じリクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報が、所定時間内に受信できなかった場合にイネーブラ２７ｂ及びＡＰＩ２８ｂを含む通信経路の機能不全と判断し、この機能不全と判断した通信経路に介在するＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃが、ＤＢ２１ｆのＡＰＩ互換情報に存在する際に、互換動作可能と判断するようにした。

この構成によれば、次のような作用効果を得ることができる。アプリケーション２５ａへ送信されたリクエスト情報を蓄積部２１ｂに一旦蓄積しておき、その後、アプリケーション２５ａからのリクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報を受信する。判断部２１ｄが、その受信したレスポンス情報が、蓄積されたリクエスト情報の内容に不適合の場合に機能不全と判断することができるので、正確に機能不全と判断することができる。

次に、判断部２１ｄは、リクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報が、所定時間内に受信できなかった場合にイネーブラ２７ｂ及びＡＰＩ２８ｂを含む通信経路の機能不全と判断し、この機能不全と判断した通信経路に介在するＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃが、ＤＢ２１ｆのＡＰＩ互換情報に存在する際に、互換動作可能と判断するようにした。

この構成によれば、アプリケーション２５ａへ送信されたリクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報が、所定時間内に受信できなかった際に機能不全と判断するので、タイマを設けるだけ等の簡単な構成で正確に、機能不全を判断することができる。

次に、判断部２１ｄは、リクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報がエラー情報である場合にイネーブラ２７ｂ及びＡＰＩ２８ｂを含む通信経路の機能不全と判断し、この機能不全と判断した通信経路上のＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃが、ＤＢ２１ｆのＡＰＩ互換情報に存在する際に、互換動作可能と判断するようにした。

この構成によれば、アプリケーション２５ａへ送信されたリクエスト情報を受信したイネーブラ２７ｂからの返信レスポンス情報がエラー情報であることを検出するだけで機能不全と判断するので、簡単な構成で正確に、機能不全を判断することができる。

次に、信号変換部２１ｇは、判断部２１ｄで互換動作可能と判断された際に、対応ＡＰＩ２８ｃに繋がる対応イネーブラ２７ｃへのリクエスト情報の送信後に当該対応イネーブラ２７ｃから返信されたレスポンス情報を、不適合のレスポンス情報を返信したイネーブラ２７ｂから本来適正に出力されるレスポンス情報に整合するように変換する。更に、信号送信部２１ｃは、その整合されたレスポンス情報をアプリケーション２５ａへ返信するようにした。

この構成によれば、ＡＰＩ２８ｂやイネーブラ２７ｂ等が機能不全となった場合でも、ＡＰＩ処理機能部２１が機能不全となったＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃ及び対応イネーブラ２７ｃへ切り替える互換切替動作を行う。この際、信号変換部２１ｇは、対応イネーブラ２７ｃから返信されたレスポンス情報を、機能不全のイネーブラ２７ｂから本来適正に出力されるレスポンス情報としてアプリケーション２５ａへ返信する。このため、アプリケーション２５ａを有するスマートフォン等の端末機では、イネーブラ２７等の機能不全による互換切替動作を意識することなく、所望の情報を見ることができる。つまり、アプリケーション２５ａの可用性向上によりユーザはサービスを継続して受けることができるようになる。

また、この構成の場合、イネーブラ２７ｃからのレスポンス情報によるレスポンスが、元のＡＰＩ２８ｂの動作として動くため、アプリ２５ａは互換動作を意識せずアプリ開発を行うことができる。

次に、ＡＰＩ集約装置２４は、次のＡＰＩ互換方法を実行する。即ち、ＡＰＩ集約装置２４は、アプリケーション２５ａから所望のイネーブラ２７へＡＰＩを介してリクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合に、当該機能不全のイネーブラ２７に予め対応付けられた対応イネーブラ２７からのレスポンス情報を、当該対応イネーブラ２７に繋がる対応ＡＰＩを介して当該アプリケーション２５ａへ返信するステップを実行する。
このＡＰＩ互換方法によれば、複数組み合わせたＡＰＩ２８ａ〜２８ｄの何れかが機能不全となった場合でも、その機能不全のＡＰＩ２８ｂに係る機能の情報を、そのＡＰＩ２８ｂに係る対応ＡＰＩ２８ｃを介してアプリケーション２５ａに提供することができる。

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

２０ 通信システム
２１ ＡＰＩ処理機能部
２１ａ 信号受信部
２１ｂ 信号情報蓄積部（蓄積部）
２１ｃ 信号送信部
２１ｄ 互換動作実行判断部（判断部）
２１ｅ 互換動作実行部（実行部）
２１ｆ ＡＰＩ互換情報ＤＢ（データベース）
２１ｇ 信号変換部
２２ 開発者ポータル機能部
２３ 保守運用機能部
２４ ＡＰＩ集約装置
２５ａ〜２５ｍ アプリケーション
２６ａ〜２６ｊ，２８ａ〜２８ｎ ＡＰＩ
２７ａ〜２７ｎ イネーブラ
２７ａ 位置情報取得機能（イネーブラ）
２７ｂ Ａグルメ検索機能（イネーブラ）
２７ｃ Ｂグルメ検索機能（イネーブラ）
２７ｄ レコメンド機能（イネーブラ）

Claims (7)

1. 所定の目的を少なくとも通信を行って実現するイネーブラに繋がるＡＰＩを複数組み合わせたアプリケーションが、所望の情報を取得するためのリクエスト情報を前記ＡＰＩを介して前記イネーブラへ送信し、前記送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記ＡＰＩを介して前記アプリケーションへ返信する通信システムにおいて、前記アプリケーションと前記イネーブラとの間に少なくとも前記ＡＰＩを介して接続されたＡＰＩ集約装置であって、
   前記アプリケーションから所望のイネーブラへ前記ＡＰＩを介して前記リクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合、当該機能不全のイネーブラに予め対応付けられた対応イネーブラからのレスポンス情報を、当該対応イネーブラに繋がる対応ＡＰＩを介して当該アプリケーションへ返信するＡＰＩ処理機能部
   を備えることを特徴とするＡＰＩ集約装置。
2. 前記ＡＰＩ処理機能部は、
   前記ＡＰＩ毎に繋がる機能に互換性が有る場合に、その互換性の有るＡＰＩの対応関係を示すＡＰＩ互換情報を記憶するデータベースと、
   前記アプリケーションから送信されるリクエスト情報を受信したイネーブラが返信するレスポンス情報を受信した際に、当該レスポンス情報が予め定められた規定の内容に不適合の場合、当該不適合のレスポンス情報を返信したイネーブラに繋がるＡＰＩに係る前記対応ＡＰＩが、前記データベースのＡＰＩ互換情報に存在すれば、互換動作可能と判断する判断部と、
   前記互換動作可能と判断された際に、前記不適合のレスポンス情報を返信したイネーブラへのリクエスト情報を、前記対応ＡＰＩに繋がる対応イネーブラへのリクエスト情報に変換し、この変換されたリクエスト情報を対応イネーブラへ送信する変換部と、
   前記変換されたリクエスト情報を受信した対応イネーブラから返信されるレスポンス情報を、前記アプリケーションへ返信する送信部と、
   を備えることを特徴とする請求項１に記載のＡＰＩ集約装置。
3. 前記ＡＰＩ処理機能部は、
   前記アプリケーションから送信されたリクエスト情報を蓄積する蓄積部を更に備え、
   前記判断部は、前記アプリケーションから送信されるリクエスト情報を受信したイネーブラから返信されたレスポンス情報を受信した際に、当該受信したレスポンス情報が、前記蓄積されたリクエスト情報の内容に不適合の場合に、前記イネーブラ及び前記ＡＰＩを含む通信経路の双方の機能不全と判断し、この機能不全と判断した通信経路上の当該イネーブラに繋がるＡＰＩに係る前記対応ＡＰＩが、前記データベースのＡＰＩ互換情報に存在すれば、互換動作可能と判断する
   ことを特徴とする請求項２に記載のＡＰＩ集約装置。
4. 前記判断部は、前記リクエスト情報を受信した前記イネーブラからの返信レスポンス情報が、所定時間内に受信できなかった場合に、イネーブラ及びＡＰＩを含む通信経路の双方の機能不全と判断し、この機能不全と判断した通信経路の当該イネーブラに繋がるＡＰＩに係る前記対応ＡＰＩが、前記データベースのＡＰＩ互換情報に存在する際に、互換動作可能と判断する
   ことを特徴とする請求項２に記載のＡＰＩ集約装置。
5. 前記判断部は、前記リクエスト情報を受信した前記イネーブラからの返信レスポンス情報がエラー情報である場合に、イネーブラ及びＡＰＩを含む通信経路の双方の機能不全と判断し、この機能不全と判断した通信経路の当該イネーブラに繋がるＡＰＩに係る前記対応ＡＰＩが、前記データベースのＡＰＩ互換情報に存在する際に、互換動作可能と判断する
   ことを特徴とする請求項２に記載のＡＰＩ集約装置。
6. 前記変換部は、前記判断部で前記互換動作可能と判断された際に、前記対応ＡＰＩに繋がる対応イネーブラへのリクエスト情報の送信後に当該対応イネーブラから返信されたレスポンス情報を、前記不適合のレスポンス情報を返信したイネーブラから本来適正に出力されるレスポンス情報に整合するように変換し、
   前記送信部は、前記整合されたレスポンス情報を前記アプリケーションへ返信する
   ことを特徴とする請求項２〜５の何れか１項に記載のＡＰＩ集約装置。
7. 所定の目的を少なくとも通信を行って実現するイネーブラに繋がるＡＰＩを複数組み合わせたアプリケーションが、所望の情報を取得するためのリクエスト情報を前記ＡＰＩを介して前記イネーブラへ送信し、前記送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記ＡＰＩを介して前記アプリケーションへ返信する通信システムにおいて、前記アプリケーションと前記イネーブラとの間に少なくとも前記ＡＰＩを介して接続されたＡＰＩ集約装置によるＡＰＩ集約方法であって、
   前記ＡＰＩ集約装置は、
   前記アプリケーションから所望のイネーブラへ前記ＡＰＩを介して前記リクエスト情報を送信した際に、当該リクエスト情報の内容に適合したレスポンス情報が返信されない機能不全の場合、当該機能不全のイネーブラに予め対応付けられた対応イネーブラからのレスポンス情報を、当該対応イネーブラに繋がる対応ＡＰＩを介して当該アプリケーションへ返信するステップ
   を実行することを特徴とするＡＰＩ互換方法。

Images