(57)【要約】【課題】エンドユーザによるＷｅｂＡＰＩの実行結果の新鮮度の検証を可能とする。【解決手段】ＷｅｂＡＰＩ新鮮度検証システム１のユーザ端末１０（端末装置）は、アプリケーションサーバ２０を介して、リソース提供サーバ３０から、新鮮度を検証するためのＡＰＩ検証コードと、確認用ＡＰＩのエンドポイントとが付されたＡＰＩ実行結果情報を取得する。そして、ユーザ端末１０は、ＡＰＩ検証コードを付した新鮮度確認要求メッセージを、確認用ＡＰＩのエンドポイントに向けて送信する。ＡＰＩ検証コードが付された新鮮度確認要求メッセージを受信したリソース提供サーバ３０は、当該ＡＰＩ検証コードで示されるＡＰＩ実行結果情報が最新の情報か否かを検証し、その検証結果をユーザ端末１０に送信する。【選択図】図１
2016224789.tif 000002
【特許請求の範囲】
【請求項１】
ＷｅｂＡＰＩ（Web Application Programming Interface）を実行することによりアプリケーションサーバからＡＰＩ実行結果を取得する端末装置と、前記アプリケーションサーバからの要求を受け付けて前記ＡＰＩ実行結果を生成し、前記アプリケーションサーバに送信するリソース提供サーバと、を備えるＷｅｂＡＰＩ新鮮度検証システムであって、
前記端末装置は、
前記ＷｅｂＡＰＩを用いて要求メッセージを前記アプリケーションサーバに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を、前記アプリケーションサーバを介して取得するＷｅｂＡＰＩ実行部と、
前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するＷｅｂＡＰＩ新鮮度確認部と、を備え、
前記リソース提供サーバは、
前記アプリケーションサーバを介して前記要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として前記ＡＰＩ検証コードを発行し、前記ＡＰＩ検証コードおよび前記確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を、前記アプリケーションサーバに送信するＷｅｂＡＰＩリソース提供部と、
前記新鮮度確認要求メッセージを受信した場合に、当該新鮮度確認要求メッセージに付された前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成して前記端末装置に送信する確認用ＡＰＩ実行部と、を備えること
を特徴とするＷｅｂＡＰＩ新鮮度検証システム。
【請求項２】
ＷｅｂＡＰＩを実行することによりアプリケーションサーバからＡＰＩ実行結果を取得する端末装置と、前記アプリケーションサーバからの要求を受け付けて前記ＡＰＩ実行結果を生成し、前記アプリケーションサーバに送信するリソース提供サーバと、を備えるＷｅｂＡＰＩ新鮮度検証システムのＷｅｂＡＰＩ新鮮度検証方法であって、
前記端末装置は、
前記ＷｅｂＡＰＩを用いて要求メッセージを前記アプリケーションサーバに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を、前記アプリケーションサーバを介して取得するステップと、
前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するステップと、を実行し、
前記リソース提供サーバは、
前記アプリケーションサーバを介して前記要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として前記ＡＰＩ検証コードを発行し、前記ＡＰＩ検証コードおよび前記確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を、前記アプリケーションサーバに送信するステップと、
前記新鮮度確認要求メッセージを受信した場合に、当該新鮮度確認要求メッセージに付された前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成して前記端末装置に送信するステップと、を実行すること
を特徴とするＷｅｂＡＰＩ新鮮度検証方法。
【請求項３】
ＷｅｂＡＰＩを実行することによりＡＰＩ実行結果を生成するリソース提供サーバであって、
前記ＷｅｂＡＰＩを用いた要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードを発行し、前記ＡＰＩ検証コード、および、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を送信するＷｅｂＡＰＩリソース提供部と、
前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを受信した場合に、前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成する確認用ＡＰＩ実行部と、
を備えることを特徴とするリソース提供サーバ。
【請求項４】
コンピュータに、請求項３に記載のリソース提供サーバの各機能を実現させるためのプログラム。
【請求項５】
ＷｅｂＡＰＩを実行することによりＡＰＩ実行結果を取得する端末装置であって、
前記ＷｅｂＡＰＩを用いて要求メッセージを送信することにより、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を取得するＷｅｂＡＰＩ実行部と、
前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するＷｅｂＡＰＩ新鮮度確認部と、
を備えることを特徴とする端末装置。
【請求項６】
コンピュータに、請求項５に記載の端末装置の各機能を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷｅｂＡＰＩ（Web Application Programming Interface）を利用したアプリケーション（Application software）（以下、「アプリ」と称する場合がある。）が提示する情報の信頼性を向上させるための技術分野であり、ＷｅｂＡＰＩ新鮮度検証システム、ＷｅｂＡＰＩ新鮮度検証方法、リソース提供サーバ、端末装置、および、プログラムに関する。
【背景技術】
【０００２】
スマートフォンにおいて利用されるスマホアプリや、ＰＣ（Personal Computer）、タブレット端末等において利用されるＷｅｂアプリにおいて、アプリ開発者（アプリサーバ）が、当該アプリの要求する情報を、ＷｅｂＡＰＩにより外部リソースを利用して提供する機会が増えている。これらのアプリを利用してエンドユーザが取得するリソース（情報）は、「ＷｅｂＡＰＩの１次提供者サーバ」→「アプリケーションサーバ」→「アプリ（ユーザ端末）」のように、通信ネットワークを介して接続された複数の装置を経由する場合が多い。この際、各装置では取得した情報をキャッシュに保持し、情報の取得要求が再度あった場合に、キャッシュに保持した情報を用いて応答している。
【０００３】
一方、ＨＴＴＰ（Hyper Text Transfer Protocol）を用いてＨＴＭＬ（HyperText Markup Language）等の文書を送受信するＷｅｂＡＰＩにおいて、キャッシュに有効期限を設定したり、キャッシュ全体を無効にしたり等のキャッシュを制御するサーバ側の仕様として、以下が知られている。
（１）ＨＴＴＰの仕様：Cache-Controlヘッダ（非特許文献１参照）
（２）ＨＴＭＬの仕様：METAタグ
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="有効期限 ">
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】RFC1945，“Hypertext Transfer Protocol - HTTP/1.0，” ［online］，May 1996，［平成27年5月22日検索］，インターネット<ＵＲＬ：http://www.isi.edu/in-notes/rfc1945.txt>
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、アプリを実行して取得した情報については、前記したようにキャッシュに保持された情報が提示される可能性があるため、時間の経過とともに変化し得る情報をＷｅｂＡＰＩにより取得する場合、エンドユーザは、アプリの提示するリソース（情報）が現在も有効、つまり最新の情報であるか否かを検証できなかった。即ち、エンドユーザは、リソースが更新されているにもかかわらず更新前の古い情報が表示されていることを検証できなかった。なお、リソース（情報）が現在も有効（最新の情報）であるか否かの検証を、以下、「新鮮度」の検証と称する場合がある。
【０００６】
上記した状況においては、例えば、「ネットワークの故障情報を提供するＡＰＩにおいて、ネットワークの故障が実際には回復しているにもかかわらず、故障中のまま表示される」「Ｅコマース系のＡＰＩにおいて、セールが終了したにもかかわらず、セール価格のまま表示される」等が発生し得る。
【０００７】
この問題に関し、前記した非特許文献１等のように、ＷｅｂＡＰＩの１次提供者（リソースの提供者）側でキャッシュを抑制する手段は従来技術として存在するが、リソースをキャッシュしないようにサーバ側（後記する「リソース提供サーバ」（ＷｅｂＡＰＩの１次提供者サーバ））がクライアント側（後記する「アプリケーションサーバ」や「ユーザ端末」）に対して通知するのみで、実際にキャッシュをどのように制御するかは、クライアント側の善意や実装に依存している。つまり、従来技術を用いて、ＷｅｂＡＰＩの１次提供者側から、キャッシュを制御する指示情報を送信しても、その指示情報に従わない若しくはその指示情報を無視するような悪意のある設定がなされたアプリケーションサーバ等に、その指示情報を実行させる手立てはない。また、悪意はなくてもアプリケーションサーバ等の設定ミス、アプリ開発者の実装ミスが存在する場合には、それらを防ぐ手立てはＷｅｂＡＰＩの１次提供者側にはない。
【０００８】
つまり、現状では、ＷｅｂＡＰＩの１次提供者の立場としては、適切にキャッシュ情報を設定しようとしたとしても、エンドユーザに有効期限切れの情報を伝えてしまうおそれがある。
また、アプリ開発者の立場としては、自身がエンドユーザに提供する２次情報（ＷｅｂＡＰＩの１次提供者から取得したリソース）の真偽を、ユーザに確認させる方法が存在しない。
エンドユーザの立場としては、例えば、決済などの重要な動作（時間の経過とともに変化し得る情報に対する処理）を行う際でも、アプリが提示した情報の新鮮度を検証できない、こととなっている。
【０００９】
キャッシュは、通常、表示速度の高速化やサーバの負荷軽減の目的のために利用されるが、それ以外にも、ＷｅｂＡＰＩの利用においては、リクエスト回数やデータ量に応じて、アプリ開発者に支払うエンドユーザへの課金や、ＷｅｂＡＰＩの１次提供者に支払うアプリ開発者への課金等が行われるため、できるだけＷｅｂＡＰＩの実行結果をキャッシュするモチベーションがある。
【００１０】
このような背景を鑑みて本発明がなされたのであり、本発明は、エンドユーザがＷｅｂＡＰＩの実行結果の新鮮度を検証することができる、ＷｅｂＡＰＩ新鮮度検証システム、ＷｅｂＡＰＩ新鮮度検証方法、リソース提供サーバ、端末装置、および、プログラムを提供することを課題とする。
【課題を解決するための手段】
【００１１】
前記した課題を解決するため、請求項１に記載の発明は、ＷｅｂＡＰＩを実行することによりアプリケーションサーバからＡＰＩ実行結果を取得する端末装置と、前記アプリケーションサーバからの要求を受け付けて前記ＡＰＩ実行結果を生成し、前記アプリケーションサーバに送信するリソース提供サーバと、を備えるＷｅｂＡＰＩ新鮮度検証システムであって、前記端末装置が、前記ＷｅｂＡＰＩを用いて要求メッセージを前記アプリケーションサーバに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を、前記アプリケーションサーバを介して取得するＷｅｂＡＰＩ実行部と、前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するＷｅｂＡＰＩ新鮮度確認部と、を備え、前記リソース提供サーバが、前記アプリケーションサーバを介して前記要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として前記ＡＰＩ検証コードを発行し、前記ＡＰＩ検証コードおよび前記確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を、前記アプリケーションサーバに送信するＷｅｂＡＰＩリソース提供部と、前記新鮮度確認要求メッセージを受信した場合に、当該新鮮度確認要求メッセージに付された前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成して前記端末装置に送信する確認用ＡＰＩ実行部と、を備えることを特徴とするＷｅｂＡＰＩ新鮮度検証システムとした。
【００１２】
請求項２に記載の発明は、ＷｅｂＡＰＩを実行することによりアプリケーションサーバからＡＰＩ実行結果を取得する端末装置と、前記アプリケーションサーバからの要求を受け付けて前記ＡＰＩ実行結果を生成し、前記アプリケーションサーバに送信するリソース提供サーバと、を備えるＷｅｂＡＰＩ新鮮度検証システムのＷｅｂＡＰＩ新鮮度検証方法であって、前記端末装置が、前記ＷｅｂＡＰＩを用いて要求メッセージを前記アプリケーションサーバに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を、前記アプリケーションサーバを介して取得するステップと、前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記リソース提供サーバから、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するステップと、を実行し、前記リソース提供サーバが、前記アプリケーションサーバを介して前記要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として前記ＡＰＩ検証コードを発行し、前記ＡＰＩ検証コードおよび前記確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を、前記アプリケーションサーバに送信するステップと、前記新鮮度確認要求メッセージを受信した場合に、当該新鮮度確認要求メッセージに付された前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成して前記端末装置に送信するステップと、を実行することを特徴とするＷｅｂＡＰＩ新鮮度検証方法とした。
【００１３】
このようにすることで、ＷｅｂＡＰＩ新鮮度検証システムは、アプリケーションサーバを経由せずに、ユーザ端末がリソース提供サーバに、直接、ＷｅｂＡＰＩの新鮮度を問い合わせ、その検証結果を取得することが可能となる。よって、エンドユーザは、ＷｅｂＡＰＩの新鮮度を検証した上で、時間の経過とともに変化し得る情報等に対する処理を実行することができる。
【００１４】
請求項３に記載の発明は、ＷｅｂＡＰＩを実行することによりＡＰＩ実行結果を生成するリソース提供サーバであって、前記ＷｅｂＡＰＩを用いた要求メッセージを受信した場合に、前記ＡＰＩ実行結果を生成するとともに、前記生成したＡＰＩ実行結果に対応付けた情報として、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードを発行し、前記ＡＰＩ検証コード、および、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントを付した前記ＡＰＩ実行結果を送信するＷｅｂＡＰＩリソース提供部と、前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを受信した場合に、前記ＡＰＩ検証コードを用いて前記ＡＰＩ実行結果を特定し、前記特定したＡＰＩ実行結果が最新の情報であるか否かを検証し、前記新鮮度の検証結果を生成する確認用ＡＰＩ実行部と、を備えることを特徴とするリソース提供サーバとした。
【００１５】
このようにすることで、リソース提供サーバは、ＷｅｂＡＰＩの実行結果（ＡＰＩ実行結果）の新鮮度を検証する手段を提供することができる。よって、リソース提供サーバは、エンドユーザ等の要求に応じて、ＷｅｂＡＰＩの最新情報を確実に提供することが可能となる。
【００１６】
請求項４に記載の発明は、コンピュータに、請求項３に記載のリソース提供サーバの各機能を実現させるためのプログラムとした。
【００１７】
このようにすることで、一般的なコンピュータを用いて、請求項３に記載のリソース提供サーバの各部の機能を実現させることができる。
【００１８】
請求項５に記載の発明は、ＷｅｂＡＰＩを実行することによりＡＰＩ実行結果を取得する端末装置であって、前記ＷｅｂＡＰＩを用いて要求メッセージを送信することにより、前記ＡＰＩ実行結果が最新の情報か否かを示す新鮮度の検証に用いるＡＰＩ検証コードと、前記新鮮度を検証するための確認用ＡＰＩのエンドポイントと、が付された前記ＡＰＩ実行結果を取得するＷｅｂＡＰＩ実行部と、前記ＡＰＩ検証コードを付した新鮮度確認要求メッセージを生成し、前記確認用ＡＰＩのエンドポイントに送信することにより、前記ＡＰＩ実行結果の前記新鮮度の検証結果を取得するＷｅｂＡＰＩ新鮮度確認部と、を備えることを特徴とする端末装置とした。
【００１９】
このようにすることで、端末装置（ユーザ端末）は、ＷｅｂＡＰＩの実行結果（ＡＰＩ実行結果）の新鮮度の検証が可能となる。よって、端末装置は、ＷｅｂＡＰＩの新鮮度を検証した上で、時間の経過とともに変化し得る情報等に対する処理を実行することができる。
【００２０】
請求項６に記載の発明は、コンピュータに、請求項５に記載の端末装置の各機能を実現させるためのプログラムとした。
【００２１】
このようにすることで、一般的なコンピュータを用いて、請求項５に記載の端末装置の各部の機能を実現させることができる。
【発明の効果】
【００２２】
本発明によれば、エンドユーザによるＷｅｂＡＰＩの実行結果の新鮮度の検証を可能とする、ＷｅｂＡＰＩ新鮮度検証システム、ＷｅｂＡＰＩ新鮮度検証方法、リソース提供サーバ、端末装置、および、プログラムを提供することができる。
【図面の簡単な説明】
【００２３】
【図１】本実施形態に係るＷｅｂＡＰＩ新鮮度検証システムの全体構成と各装置の機能ブロックを示す図である。
【図２】本実施形態に係るＷｅｂＡＰＩ新鮮度検証システムの処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【００２４】
次に、本発明を実施するための形態（以下、本実施形態と称する。）における、ＷｅｂＡＰＩ新鮮度検証システム１等について説明する。
【００２５】
≪概要≫
まず、本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１の概要について説明する。
図１は、本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１の全体構成と各装置の機能ブロックを示す図である。
【００２６】
本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１は、図１に示すように、エンドユーザが備えるユーザ端末１０（端末装置）と、アプリ開発者が管理・運営するアプリケーションサーバ２０と、アプリケーションサーバ２０からの要求に対しＷｅｂＡＰＩによりリソース（情報）を提供する１次提供者（前記した「ＷｅｂＡＰＩの１次提供者」）が管理・運営するリソース提供サーバ３０（前記した「ＷｅｂＡＰＩの１次提供者サーバ」）とを備えて構成される。
ここで、ユーザ端末１０は、図１に示す１台に限定されず１台以上であればよい。また、ＷｅｂＡＰＩの１次提供者は、ＡＰＩの実行結果が現在も有効（最新の情報）であるか否か（新鮮度）を検証するＡＰＩ（以下、「確認用ＡＰＩ」と称する。詳細は後記する。）を公開している。ユーザ端末１０は、通信ネットワークを介して、アプリケーションサーバ２０と接続されるとともに、この確認用ＡＰＩを用いて、リソース提供サーバ３０とも接続される。一方、リソース提供サーバ３０は、アプリケーションサーバ２０と接続されるとともに、ユーザ端末１０とも接続される。
【００２７】
ユーザ端末１０は、ＷｅｂＡＰＩを実行することにより、要求メッセージをアプリケーションサーバ２０に送信し、アプリケーションサーバ２０が、その要求メッセージをリソース提供サーバ３０に送信する。リソース提供サーバ３０は、新鮮度を検証するためのコードであるAPI Verification Code（ＡＰＩ検証コード、以下、「ＡＶＣ」と称する場合がある。）と、確認用ＡＰＩのエンドポイント（確認用ＡＰＩが外部に公開している機能の所在を示すネットワーク上のアドレス）とを、ＷｅｂＡＰＩの実行結果に付した応答メッセージを生成し、ユーザ端末１０に送信する。ユーザ端末１０は、時間の経過とともに変化し得る情報等の取得やそれに伴う処理（例えば、決済など）をする際に、ＷｅｂＡＰＩの１次提供者により公開された確認用ＡＰＩのエンドポイントにＡＰＩ検証コード（ＡＶＣ）を送信する。ＡＰＩ検証コード（ＡＶＣ）をユーザ端末１０から受信したリソース提供サーバ３０は、当該ＡＰＩ検証コード（ＡＶＣ）で示される情報が現在も有効であるか否か、つまり、最新の情報であるか否かを検証し、その検証結果をユーザ端末１０に送信する。
【００２８】
このようにすることにより、ＷｅｂＡＰＩ新鮮度検証システム１は、アプリケーションサーバ２０などの情報の仲介者を経由せずに、ＷｅｂＡＰＩのリソースの１次提供者サーバ（リソース提供サーバ３０）とユーザ端末１０との間で、直接、ＷｅｂＡＰＩの新鮮度の検証を行うことが可能となる。よって、エンドユーザは、ＷｅｂＡＰＩの新鮮度を検証した上で、（時間の経過とともに変化し得る情報等に対する）重要な処理（決済など）を実行することができる。
【００２９】
≪各装置の構成≫
次に、本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１を構成する各装置の構成について説明する。
【００３０】
＜ユーザ端末＞
本実施形態に係るユーザ端末１０は、スマートフォンやタブレット端末、ＰＣ等のエンドユーザが備える端末装置であり、ＷｅｂＡＰＩを実行することにより、アプリケーションサーバ２０から情報を取得する。また、ユーザ端末１０は、ＷｅｂＡＰＩの１次提供者が公開した確認用ＡＰＩを用いて、ＡＰＩの実行結果の新鮮度（現在も有効であるか否か、最新の情報であるか否か）を、アプリケーションサーバ２０を介さずに、直接ＷｅｂＡＰＩの１次提供者が管理するリソース提供サーバ３０に問い合わせて検証を行う。
このユーザ端末１０は、図１に示すように、制御部１１と、入出力部１２と、記憶部１３と、表示部１４とを備える。
【００３１】
入出力部１２は、アプリケーションサーバ２０やリソース提供サーバ３０等の外部装置との間で情報の送受信を行う通信インタフェースと、図示を省略したキーボード、タッチパネル等の入力装置や、液晶ディスプレイ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。表示部１４は、液晶ディスプレイ等の表示装置（出力装置）により構成される。
【００３２】
記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成され、外部装置から取得した情報を一時的に記憶しておく領域として、キャッシュ保持部１３１を備える。
【００３３】
制御部１１は、ユーザ端末１０が実行する処理の全般を司り、ＷｅｂＡＰＩ実行部１１１、キャッシュ処理部１１２およびＷｅｂＡＰＩ新鮮度確認部１１３を含んで構成される。なお、制御部１１は、例えば、ユーザ端末１０の記憶部１３に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭ（Random Access Memory）に展開し実行することにより実現される。
【００３４】
ＷｅｂＡＰＩ実行部１１１は、ＷｅｂＡＰＩの機能を用いて要求メッセージをアプリケーションサーバ２０に送信する。そして、ＷｅｂＡＰＩ実行部１１１は、ＷｅｂＡＰＩの実行結果（以下、「ＡＰＩ実行結果情報」と称する場合がある。）を含む応答メッセージを受信し、キャッシュ処理部１１２を介してそのＡＰＩ実行結果情報を記憶部１３のキャッシュ保持部１３１等に記憶させるとともに、そのＡＰＩ実行結果情報を表示部１４に表示させる。
なお、ＷｅｂＡＰＩ実行部１１１は、要求メッセージを生成した際に、まず、キャッシュ処理部１１２を介して、記憶部１３内のキャッシュ保持部１３１に、要求しようとしているリソース（ＡＰＩ実行結果情報）を記憶しているか否かを問い合わせ、記憶している場合には、そのキャッシュしているリソース（ＡＰＩ実行結果情報）を取得して、表示部１４に表示させる。
【００３５】
キャッシュ処理部１１２は、ＷｅｂＡＰＩ実行部１１１の処理により受信したＡＰＩ実行結果情報を、記憶部１３内のキャッシュ保持部１３１に記憶する。なお、このＡＰＩ実行結果情報には、ＷｅｂＡＰＩの１次提供者により公開された確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されている。なお、この確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とは、後記するように、リソース提供サーバ３０が、ＡＰＩ実行結果情報に付すものである。
また、キャッシュ処理部１１２は、予め設定された有効期限を越えたリソース（ＡＰＩ実行結果情報）をキャッシュ保持部１３１から消去したり等のキャッシュ全般の処理を行う。そして、キャッシュ処理部１１２は、ＷｅｂＡＰＩ実行部１１１からの問い合わせを受け、要求メッセージに示されるリソース（ＡＰＩ実行結果情報）をキャッシュ保持部１３１に記憶しているか否かを検出し、記憶している場合には、その情報をＷｅｂＡＰＩ実行部１１１に出力する。一方、キャッシュ処理部１１２は、キャッシュ保持部１３１に記憶していない場合には、その旨の情報をＷｅｂＡＰＩ実行部１１１に出力する。
【００３６】
ＷｅｂＡＰＩ新鮮度確認部１１３は、例えば、ＷｅｂＡＰＩの１次提供者により公開された確認用ＡＰＩを実行するために、表示部１４に表示された、新鮮度確認ボタンが押し下げられたこと等の情報を、入出力部１２を介して取得すると、新鮮度の検証を要求する情報のＡＰＩ検証コード（ＡＶＣ）を、記憶部１３内のキャッシュ保持部１３１等から取得し、当該ＡＰＩ検証コード（ＡＶＣ）を付した新鮮度確認要求メッセージを生成する。そして、ＷｅｂＡＰＩ新鮮度確認部１１３は、同じくキャッシュ保持部１３１等に記憶されたＡＰＩ実行結果情報に付された確認用ＡＰＩのエンドポイントに向けて、生成した新鮮度確認要求メッセージを送信する。
また、ＷｅｂＡＰＩ新鮮度確認部１１３は、リソース提供サーバ３０から、新鮮度確認要求メッセージに対する応答として、ＷｅｂＡＰＩの実行結果が現在も有効（最新の情報）であるか否か示す検証結果情報を含む新鮮度確認応答メッセージを受信し、表示部１４に表示させる。
【００３７】
このようにすることにより、ユーザ端末１０は、従来技術では対応できなかった、エンドユーザによるＡＰＩ実行結果の新鮮度の検証が可能となる。よって、重要な処理（決済など）を実行する際に、ユーザは、アプリが提供している情報が、現在も有効、つまり最新の情報であるか否かを確認した上で、処理を実行することができる。
【００３８】
＜アプリケーションサーバ＞
アプリケーションサーバ２０は、ユーザ端末１０からの要求メッセージを受け付け、その要求メッセージの処理に必要となる情報（リソース）を記憶するリソース提供サーバ３０に向けて、当該要求メッセージを送信する。そして、アプリケーションサーバ２０は、リソース提供サーバ３０からＡＰＩ実行結果情報を含む応答メッセージを受け取り、その情報をキャッシュとして保持するとともに、要求メッセージを送信してきたユーザ端末１０に送信する。
このアプリケーションサーバ２０は、図１に示すように、制御部２１と、入出力部２２と、記憶部２３とを備える。
【００３９】
入出力部２２は、ユーザ端末１０やリソース提供サーバ３０等との間で情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力装置や、出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
【００４０】
記憶部２３は、ハードディスクやフラッシュメモリ、ＲＡＭ等により構成され、外部装置から取得した情報を一時的に記憶しておく領域として、キャッシュ保持部２３１を備える。
【００４１】
制御部２１は、アプリケーションサーバ２０が実行する処理の全般を司り、ＷｅｂＡＰＩ処理部２１１と、キャッシュ処理部２１２とを含んで構成される。なお、制御部２１は、例えば、アプリケーションサーバ２０の記憶部２３に格納されたプログラムをＣＰＵがＲＡＭに展開し実行することにより実現される。
【００４２】
ＷｅｂＡＰＩ処理部２１１は、ユーザ端末１０から要求メッセージを受け付け、その要求メッセージの処理に必要となる情報（リソース）を記憶するリソース提供サーバ３０に向けて、当該要求メッセージを送信する。また、ＷｅｂＡＰＩ処理部２１１は、ＷｅｂＡＰＩの実行結果（ＡＰＩ実行結果情報）を含む応答メッセージをリソース提供サーバ３０から受信し、キャッシュ処理部２１２を介してそのＡＰＩ実行結果情報を記憶部２３に記憶させる。また、ＷｅｂＡＰＩ処理部２１１は、受信した応答メッセージを、要求メッセージを送信してきたユーザ端末１０に送信する。
なお、ＷｅｂＡＰＩ処理部２１１は、ユーザ端末１０から要求メッセージを受け付けた際に、まず、キャッシュ処理部２１２を介して、記憶部２３内のキャッシュ保持部２３１に、受け付けた要求に対応するリソース（ＡＰＩ実行結果情報）を記憶しているか否かを問い合わせ、記憶している場合には、そのキャッシュしているリソース（ＡＰＩ実行結果情報）を取得して、ユーザ端末１０に送信する。
【００４３】
キャッシュ処理部２１２は、ＷｅｂＡＰＩ処理部２１１の処理により受信した応答メッセージに含まれるＡＰＩ実行結果情報を、記憶部２３内のキャッシュ保持部２３１に記憶する。なお、このＡＰＩ実行結果情報には、リソース提供サーバ３０により、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されている。
また、キャッシュ処理部２１２は、予め設定された有効期限を越えたリソース（ＡＰＩ実行結果情報）をキャッシュ保持部２３１から消去したり等のキャッシュ全般の処理を行う。そして、キャッシュ処理部２１２は、ＷｅｂＡＰＩ処理部２１１からの問い合わせを受け、要求メッセージに示されるリソース（ＡＰＩ実行結果情報）をキャッシュ保持部２３１に記憶しているか否かを検出し、記憶している場合には、その情報をＷｅｂＡＰＩ処理部２１１に出力する。一方、キャッシュ処理部２１２は、キャッシュ保持部２３１に記憶していない場合には、その旨の情報をＷｅｂＡＰＩ処理部２１１に出力する。
【００４４】
このようにすることにより、アプリケーションサーバ２０は、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報をリソース提供サーバ３０から取得し、自身のキャッシュ保持部２３１に記憶するとともに、応答メッセージとしてユーザ端末１０に送信することができる。
【００４５】
＜リソース提供サーバ＞
リソース提供サーバ３０は、アプリケーションサーバ２０から要求メッセージを受信し、ＷｅｂＡＰＩの実行結果となるリソース３００を記憶部３３から取得し、ＡＰＩ実行結果情報を生成する。また、リソース提供サーバ３０は、ＡＰＩ実行結果情報を生成する毎に、そのＡＰＩ実行結果情報として抽出した個々のリソース３００の情報（以下、「ＷｅｂＡＰＩ提供リソース」と称する。）に対応付けてＡＰＩ検証コード（ＡＶＣ）を生成する。そして、リソース提供サーバ３０は、生成したＡＰＩ実行結果情報に、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）と付して、応答メッセージを生成しアプリケーションサーバ２０に送信する。また、リソース提供サーバ３０は、生成したＡＰＩ検証コード（ＡＶＣ）と、ＷｅｂＡＰＩ提供リソースとを対応付けて、ＡＶＣリソース対応情報３３０（図１参照）として記憶部３３に記憶しておく。リソース提供サーバ３０は、ユーザ端末１０から、新鮮度確認要求メッセージを受信すると、その新鮮度確認要求メッセージに付されたＡＰＩ検証コード（ＡＶＣ）に基づき、ＡＶＣリソース対応情報３３０を参照してＷｅｂＡＰＩ提供リソースを特定する。そして、リソース提供サーバ３０は、特定したＷｅｂＡＰＩ提供リソースが、現在も有効（最新の情報）であるか否かを、最新の情報が反映されているリソース３００を参照することにより検証し、その検証結果情報を含む新鮮度確認応答メッセージをユーザ端末１０に送信する。
このリソース提供サーバ３０は、図１に示すように、制御部３１と、入出力部３２と、記憶部３３とを備える。
【００４６】
入出力部３２は、ユーザ端末１０やアプリケーションサーバ２０等との間で情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力装置や、出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
【００４７】
記憶部３３は、ハードディスクやフラッシュメモリ、ＲＡＭ等により構成され、ＡＶＣリソース対応情報３３０や、リソース３００等が記憶される。また、この記憶部３３には、ＡＰＩ実行結果情報に付される確認用ＡＰＩのエンドポイント（アドレス）の情報が予め記憶される。
【００４８】
ＡＶＣリソース対応情報３３０には、図１に示すように、後記するＷｅｂＡＰＩリソース提供部３１１のＡＰＩ検証コード発行部３１２（図１では「ＡＶＣ発行部３１２」と省略して記載する。）が発行したＡＰＩ検証コード（ＡＶＣ）と、ＡＰＩ実行結果情報としてリソース３００から取得したＷｅｂＡＰＩ提供リソースと、が対応付けて記憶される。また、このＡＶＣリソース対応情報３３０のＷｅｂＡＰＩ提供リソースは、ＡＰＩ実行時点においてリソース３００から取得したＷｅｂＡＰＩ提供リソースが特定できる態様で記憶されるとともに、そのＷｅｂＡＰＩ提供リソースが、現在も有効（最新の情報）であるか否か（新鮮度）を検証できる態様で記憶される。例えば、ＷｅｂＡＰＩ提供リソースの情報そのものでもよいし、リソース提供サーバ３０がリソース３００のバージョン情報を管理情報として記憶している場合には、ＷｅｂＡＰＩ提供リソースの識別情報にＡＰＩ実行時点のバージョン情報を付した情報でもよい。また、リソース提供サーバ３０がリソース３００の更新日時を管理情報として記憶している場合には、ＷｅｂＡＰＩ提供リソースの識別情報にＡＰＩ実行時点の日時を付した情報でもよい。
【００４９】
リソース３００は、リソース提供サーバ３０がＷｅｂＡＰＩにより提供するサービスに関する１次情報が記憶される。このリソース３００は、常に最新の情報が反映されて記憶される。また、最新の情報か否かを検証できるようにするため、このリソース３００を、前記したように、バージョン情報により管理したり、更新日時により管理したりしてもよい。
【００５０】
制御部３１は、リソース提供サーバ３０が実行する処理の全般を司り、ＷｅｂＡＰＩリソース提供部３１１と確認用ＡＰＩ実行部３１３とを含んで構成される。なお、制御部３１は、例えば、リソース提供サーバ３０の記憶部３３に格納されたプログラムをＣＰＵがＲＡＭに展開し実行することにより実現される。
【００５１】
ＷｅｂＡＰＩリソース提供部３１１は、アプリケーションサーバ２０から要求メッセージを受信し、ＷｅｂＡＰＩを実行することによりその実行結果の情報（ＷｅｂＡＰＩ提供リソース）を記憶部３３のリソース３００から取得し、ＡＰＩ実行結果情報を生成する。
また、ＷｅｂＡＰＩリソース提供部３１１は、ＡＰＩ検証コード発行部３１２を含んで構成される。このＡＰＩ検証コード発行部３１２は、ＡＰＩ実行結果情報が生成される毎に、ＡＰＩ検証コード（ＡＶＣ）を発行する。このＡＰＩ検証コード発行部３１２により発行されるＡＰＩ検証コード（ＡＶＣ）は、生成されるＡＰＩ実行結果情報が他のＡＰＩ実行結果情報と識別可能となるような情報（コード）であればよく、ランダムに生成される情報であってもよいし、規則性を有して生成される情報であってもよい。
【００５２】
そして、ＷｅｂＡＰＩリソース提供部３１１は、ＡＰＩ実行結果情報に、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とを付して、応答メッセージを生成し、アプリケーションサーバ２０に送信する。また、ＷｅｂＡＰＩリソース提供部３１１は、発行したＡＰＩ検証コード（ＡＶＣ）と、ＡＰＩ実行結果情報として抽出したＷｅｂＡＰＩ提供リソースを特定する情報とを対応付けてＡＶＣリソース対応情報３３０として記憶部３３に記憶しておく。
【００５３】
確認用ＡＰＩ実行部３１３は、ユーザ端末１０から、新鮮度確認要求メッセージを受信すると、その新鮮度確認要求メッセージに付されたＡＰＩ検証コード（ＡＶＣ）を取得し、ＡＶＣリソース対応情報３３０を参照してＷｅｂＡＰＩ提供リソースを特定する。そして、確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが、現時点で有効か否か、つまり、最新の情報であるか否かを、最新の情報が記憶されているリソース３００を参照することにより検証する。確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが現時点で有効（最新）の情報であればその旨（例えば、“valid”）を示す検証結果情報を付した新鮮度確認応答メッセージを生成し、ユーザ端末１０に送信する。一方、確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが現時点で有効（最新）の情報でなければその旨（例えば、“invalid”）を示す検証結果情報を付した新鮮度確認応答メッセージを生成し、ユーザ端末１０に送信する。
【００５４】
このようにすることにより、リソースの１次提供者は、エンドユーザに対して、ＷｅｂＡＰＩの結果情報（ＷｅｂＡＰＩ提供リソース）が現時点で有効か否か、つまり、最新の情報か否かを検証する手段を提供することができる。よって、エンドユーザの要求に応じて、確実にユーザ端末１０に最新情報を提供することが可能となる。
【００５５】
≪処理の流れ≫
次に、ＷｅｂＡＰＩ新鮮度検証システム１の処理を説明する。
図２は、本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１の処理の流れを示すシーケンス図である。
なお、本実施形態に係るＷｅｂＡＰＩ新鮮度検証システム１において、ユーザ端末１０は、キャッシュした情報（ＡＰＩ実行結果情報）を取得して表示する際に、自身の記憶部１３のキャッシュ保持部１３１に記憶しておいた情報（ＡＰＩ実行結果情報）を取得して表示部１４に表示する場合と、自身の記憶部１３のキャッシュ保持部１３１にＡＰＩ実行結果情報が記憶されていないため、アプリケーションサーバ２０の記憶部２３のキャッシュ保持部２３１に記憶された情報（ＡＰＩ実行結果情報）を取得して、表示部１４に表示する場合があるが、図２においては、後者の場合を例として説明する。また、図２においては、ＨＴＴＰを用いたＷｅｂＡＰＩを例として説明する。
【００５６】
まず、ユーザ端末１０のＷｅｂＡＰＩ実行部１１１は、ＷｅｂＡＰＩを実行し、要求メッセージを生成して、アプリケーションサーバ２０に送信する（ステップＳ１０）。
例えば、ユーザ端末１０は、要求メッセージとして「GET https://app.example.jp/api
/Producs?id=12345」をアプリケーションサーバ２０に送信する。
【００５７】
続いて、アプリケーションサーバ２０のＷｅｂＡＰＩ処理部２１１は、要求メッセージを受け付け、その要求メッセージの処理に必要となる情報（リソース）を記憶するリソース提供サーバ３０に向けて、当該要求メッセージを送信する（ステップＳ１１）。
例えば、アプリケーションサーバ２０は、リソース提供サーバ３０に対して、「GET https://origin.example.jp/api/producs?id=12345」を送信する。
【００５８】
次に、リソース提供サーバ３０のＷｅｂＡＰＩリソース提供部３１１は、アプリケーションサーバ２０から要求メッセージを受信し、ＷｅｂＡＰＩを実行することによりその実行結果の情報（ＷｅｂＡＰＩ提供リソース）を記憶部３３のリソース３００から取得し、ＡＰＩ実行結果情報を生成する。そして、ＡＰＩ検証コード発行部３１２が、ＡＰＩ検証コード（ＡＶＣ）を発行する（ステップＳ１２）。続いて、ＷｅｂＡＰＩリソース提供部３１１は、発行したＡＰＩ検証コード（ＡＶＣ）と、ＡＰＩ実行結果情報としてリソース３００から抽出した情報（ＷｅｂＡＰＩ提供リソース）と、を対応付けてＡＶＣリソース対応情報３３０として記憶部３３に記憶する。
【００５９】
次に、ＷｅｂＡＰＩリソース提供部３１１は、ＡＰＩ実行結果情報に、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とを付して応答メッセージを生成し、アプリケーションサーバ２０に送信する（ステップＳ１３）。
例えば、ＷｅｂＡＰＩリソース提供部３１１は、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とを付したＡＰＩ実行結果情報として、「｛name:“hikari-next”,price:“5200”,currency:“JPY”,verificationEndpoint:“https://origin.
example.jp/api/verify”, apiVerificationCode:“io4RtiIC93”｝」を生成し、応答メッセージとしてアプリケーションサーバ２０に送信する。  
【００６０】
次に、アプリケーションサーバ２０のＷｅｂＡＰＩ処理部２１１は、応答メッセージをリソース提供サーバ３０から受信し、ＡＰＩ実行結果情報、および、それに付された確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とを、キャッシュ処理部２１２を介して、記憶部２３内のキャッシュ保持部２３１に記憶する（ステップＳ１４：キャッシュに保持）。そして、アプリケーションサーバ２０のＷｅｂＡＰＩ処理部２１１は、受信した応答メッセージをユーザ端末１０に送信する（ステップＳ１５）。
【００６１】
続いて、ユーザ端末１０のＷｅｂＡＰＩ実行部１１１は、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報を含む応答メッセージを受信し、キャッシュ処理部１１２を介してその情報（確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報）を記憶部１３に記憶させるとともに、そのＡＰＩ実行結果情報を表示部１４に表示させる。
【００６２】
次に、ユーザ端末１０のＷｅｂＡＰＩ新鮮度確認部１１３は、表示部１４に表示された、新鮮度確認ボタンが押し下げられたこと等の情報を、入出力部１２を介して取得すると、取得を要求する情報のＡＰＩ検証コード（ＡＶＣ）を、記憶部１３内のキャッシュ保持部１３１等から取得し、新鮮度確認要求メッセージを生成する。そして、ＷｅｂＡＰＩ新鮮度確認部１１３は、同じくキャッシュ保持部１３１に記憶されたＡＰＩ実行結果情報に付された確認用ＡＰＩのエンドポイントの情報を取得し、そのエンドポイントに向けて、新鮮度確認要求メッセージを送信する（ステップＳ１６）。
例えば、ユーザ端末１０は、新鮮度確認要求メッセージとして、「GET https://origin.example.jp/api/verify?code=io4RtiIC93」を確認用ＡＰＩのエンドポイントに向けて送信する。
【００６３】
リソース提供サーバ３０の確認用ＡＰＩ実行部３１３は、ユーザ端末１０から、新鮮度確認要求メッセージを受信すると、その新鮮度要求メッセージに付されたＡＰＩ検証コード（ＡＶＣ）を取得し、ＡＶＣリソース対応情報３３０を参照してＷｅｂＡＰＩ提供リソースを特定する。そして、確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが、現在も有効であるか否か、つまり、最新の情報であるか否かを、リソース３００を参照して検証する。確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが現在も有効（最新の情報）であればその旨（例えば、｛status:“valid”}）を示す検証結果情報を付した新鮮度確認応答メッセージを生成し、ユーザ端末１０に送信する（ステップＳ１７）。
現在も有効（最新の情報）であることを示す検証結果情報が付された新鮮度確認応答メッセージを受信したユーザ端末１０のＷｅｂＡＰＩ新鮮度確認部１１３は、その情報を表示部１４に表示させる。
【００６４】
ここで、リソース提供サーバ３０において、リソース３００の更新があったものとする（ステップＳ２０）。つまり、ユーザ端末１０へステップＳ１３において送信したＡＰＩ実行結果情報が、更新前の情報となり最新の情報ではなくなったものとする。ただし、この時点において、アプリケーションサーバ２０のキャッシュ保持部２３１のＡＰＩ実行結果情報は更新されないままである。
【００６５】
この状態において、ユーザ端末１０のＷｅｂＡＰＩ実行部１１１が再びＷｅｂＡＰＩを実行し、要求メッセージを生成して、アプリケーションサーバ２０に送信する（ステップＳ３０）。そして、アプリケーションサーバ２０のＷｅｂＡＰＩ処理部２１１は、その要求メッセージに対するＡＰＩ実行結果情報がキャッシュ保持部２３１に記憶されていることを検出し、そのキャッシュの情報を取得して（ステップＳ３１）、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報を含む応答メッセージを生成し、ユーザ端末１０に送信する（ステップＳ３２）。
【００６６】
続いて、ユーザ端末１０のＷｅｂＡＰＩ実行部１１１は、確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報を含む応答メッセージを受信し、キャッシュ処理部２１２を介してその情報（確認用ＡＰＩのエンドポイントとＡＰＩ検証コード（ＡＶＣ）とが付されたＡＰＩ実行結果情報）を記憶部２３に記憶させるとともに、そのＡＰＩ実行結果情報を表示部１４に表示させる。
【００６７】
次に、ユーザ端末１０のＷｅｂＡＰＩ新鮮度確認部１１３は、表示部１４に表示された、新鮮度確認ボタンが押し下げられたこと等の情報を、入出力部１２を介して取得すると、取得を要求する情報のＡＰＩ検証コード（ＡＶＣ）を、記憶部１３内のキャッシュ保持部１３１から取得し、新鮮度確認要求メッセージを生成する。そして、ＷｅｂＡＰＩ新鮮度確認部１１３は、同じくキャッシュ保持部１３１に記憶されたＡＰＩ実行結果情報に付された確認用ＡＰＩのエンドポイントを取得し、そのエンドポイントに向けて、新鮮度確認要求メッセージを送信する（ステップＳ３３）。
【００６８】
リソース提供サーバ３０の確認用ＡＰＩ実行部３１３は、ユーザ端末１０から、新鮮度確認要求メッセージを受信すると、その新鮮度要求メッセージに付されたＡＰＩ検証コード（ＡＶＣ）を取得し、ＡＶＣリソース対応情報３３０を参照してＷｅｂＡＰＩ提供リソースを特定する。そして、確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが、現在も有効であるか否か、つまり、最新の情報であるか否かを検証する。ここでは、確認用ＡＰＩ実行部３１３は、特定したＷｅｂＡＰＩ提供リソースが更新されていることを検出し、当該情報が最新でない、つまり、現時点で有効でない旨（例えば、｛status:“invalid”}）を示す検証結果情報を付した新鮮度確認応答メッセージを生成し、ユーザ端末１０に送信する（ステップＳ３４）。
現時点で有効（最新）の情報ではない、つまり、情報が更新され古い情報である旨を示す検証結果情報が付された新鮮度確認応答メッセージを受信した、ユーザ端末１０のＷｅｂＡＰＩ新鮮度確認部１１３は、その情報を表示部１４に表示させる。
【００６９】
このようにすることにより、ＷｅｂＡＰＩ新鮮度検証システム１は、アプリケーションサーバ２０などの情報の仲介者を経由せずに、ＷｅｂＡＰＩのリソースの１次提供者サーバ（リソース提供サーバ３０）とユーザ端末１０との間で、直接、ＷｅｂＡＰＩにより表示される情報の新鮮度を検証することが可能となる。よって、エンドユーザは、ＷｅｂＡＰＩの新鮮度を検証した上で、（時間の経過とともに変化し得る情報等に対する）重要な処理（決済など）を実行することができる。
【符号の説明】
【００７０】
１      ＷｅｂＡＰＩ新鮮度検証システム
１０    ユーザ端末（端末装置）
１１，２１，３１  制御部
１２，２２，３２  入出力部
１３，２３，３３  記憶部
１４    表示部
１１１  ＷｅｂＡＰＩ実行部
１１２，２１２  キャッシュ処理部
１１３  ＷｅｂＡＰＩ新鮮度確認部
１３１，２３１  キャッシュ保持部
２１１  ＷｅｂＡＰＩ処理部
３００  リソース
３１１  ＷｅｂＡＰＩリソース提供部
３１２  ＡＰＩ検証コード発行部（ＡＶＣ発行部）
３１３  確認用ＡＰＩ実行部
３３０  ＡＶＣリソース対応情報
【図１】
2016224789.tif 000003
【図２】
2016224789.tif 000004