JP2017033221A - Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム - Google Patents
Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム Download PDFInfo
- Publication number
- JP2017033221A JP2017033221A JP2015151548A JP2015151548A JP2017033221A JP 2017033221 A JP2017033221 A JP 2017033221A JP 2015151548 A JP2015151548 A JP 2015151548A JP 2015151548 A JP2015151548 A JP 2015151548A JP 2017033221 A JP2017033221 A JP 2017033221A
- Authority
- JP
- Japan
- Prior art keywords
- api
- api request
- request
- redirect
- character string
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
【課題】不完全なＡＰＩリクエストによるアプリケーションの誤作動を防止すること。【解決手段】ＡＰＩリクエスト処理装置１０は、ＡＰＩ利用装置３０からのＡＰＩリクエストを処理する。リダイレクト要求部１２は、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合、ＡＰＩリクエストに含まれるクエリ文字列の末尾に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するようＡＰＩ利用装置３０に要求する。完全性判定部１４は、リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれるクエリ文字列の末尾に追加文字列が記載されているか否かに基づいて、リダイレクトＡＰＩリクエストのデータ完全性を判定する。【選択図】図１
Description
本発明は、ＡＰＩ利用装置からのＡＰＩリクエストを処理する、ＡＰＩリクエスト処理装置、ＡＰＩリクエスト処理方法およびＡＰＩリクエスト処理プログラムに関する。
従来、所定の機能をＡＰＩ（Application Programming Interface）を介してＡＰＩ利用装置（クライアント）に提供するＡＰＩ提供装置に関する技術が開発されている。
例えば、下記特許文献１は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムに関する技術であり、アプリケーションサーバによらずＡＰＩサーバを再利用することを目的としている。
また、下記特許文献２は、ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、ＡＰＩ利用者ごとに状態を管理して制限を加える認可制御を実現する技術であり、ＡＰＩ利用者からのアクセスを適切に監視して規制することを目的としている。
例えば、下記特許文献１は、アプリケーションサーバとＡＰＩサーバとから構成されるＷｅｂシステムに関する技術であり、アプリケーションサーバによらずＡＰＩサーバを再利用することを目的としている。
また、下記特許文献２は、ＡＰＩ呼出し要求に応じて呼制御ＡＰＩ又はメディア制御ＡＰＩを提供するＡＰＩゲートウェイ装置において、ＡＰＩ利用者ごとに状態を管理して制限を加える認可制御を実現する技術であり、ＡＰＩ利用者からのアクセスを適切に監視して規制することを目的としている。
ＡＰＩ利用装置がＡＰＩを実行する際、指定するクエリパラメータが多いと、ＡＰＩリクエストの文字列が長くなる場合がある。この場合、ＡＰＩ利用装置のアプリケーション実装状態によっては、アプリケーションで処理可能なＡＰＩリクエストの最大データ長を超える部分の文字列が削除された状態でＡＰＩリクエストが送信される可能性がある。
このような不完全なＡＰＩリクエストは、ＡＰＩ利用装置のユーザにとって想定外のＡＰＩリクエストとなる可能性があり、ＡＰＩ利用装置のアプリケーション等の誤動作につながる可能性がある。
上記従来技術では、このようなＡＰＩリクエストの完全性についての考慮がなされておらず、改善の余地がある。
このような不完全なＡＰＩリクエストは、ＡＰＩ利用装置のユーザにとって想定外のＡＰＩリクエストとなる可能性があり、ＡＰＩ利用装置のアプリケーション等の誤動作につながる可能性がある。
上記従来技術では、このようなＡＰＩリクエストの完全性についての考慮がなされておらず、改善の余地がある。
本発明は、このような事情に鑑みなされたものであり、その目的は、ＡＰＩ利用装置からのＡＰＩリクエストを処理する際に、不完全なＡＰＩリクエストによるアプリケーションの誤作動を防止することができる、ＡＰＩリクエスト処理装置、ＡＰＩリクエスト処理方法およびＡＰＩリクエスト処理プログラムを提供することにある。
上述の目的を達成するため、請求項１に記載の発明は、ＡＰＩ利用装置からのＡＰＩリクエストを処理するＡＰＩリクエスト処理装置であって、前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するリダイレクト要求部と、前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定する完全性判定部と、を備えることを特徴とするＡＰＩリクエスト処理装置とした。
請求項６に記載の発明は、ＡＰＩ利用装置からのＡＰＩリクエストを処理するＡＰＩリクエスト処理装置のＡＰＩリクエスト処理方法であって、前記ＡＰＩリクエスト処理装置が、前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するステップと、前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定するステップと、を実行することを特徴とするＡＰＩリクエスト処理方法とした。
請求項７に記載の発明は、ＡＰＩ利用装置からのＡＰＩリクエストを処理するコンピュータを、前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するリダイレクト要求手段、前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定する完全性判定手段、として機能させるためのＡＰＩリクエスト処理プログラムとした。
このようにすることで、ＡＰＩリクエストを処理する際にＡＰＩリクエストのデータが完全な形で受信できているか否かを判定することができる。よって、ＡＰＩ利用装置のユーザが意図しない不完全なＡＰＩリクエストによる処理を実行することを防止し、ＡＰＩリクエスト処理装置を介した処理の信頼性を向上させることができる。
請求項２に記載の発明は、前記リダイレクト要求部は、前記クエリ文字列の末尾に前記追加文字列を追加するよう要求し、前記完全性判定部は、前記クエリ文字列の末尾に前記追加文字列が記載されている場合には、前記リダイレクトＡＰＩリクエストのデータ長が前記ＡＰＩ利用装置で処理可能な前記ＡＰＩリクエストの最大データ長以内であり、前記リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定し、前記クエリ文字列の末尾に前記追加文字列が記載されていない場合には、前記リダイレクトＡＰＩリクエストのデータ長が前記最大データ長を超えており、前記リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定する、ことを特徴とする請求項１に記載のＡＰＩリクエスト処理装置とした。
このようにすることで、リダイレクトＡＰＩリクエストにおける追加文字列の有無を判定するのみでリダイレクトＡＰＩリクエストのデータ完全性を判定することができ、効率的に判定処理を実行することができる。
請求項３に記載の発明は、前記完全性判定部が前記リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定した場合、前記ＡＰＩ利用装置にエラー信号を送信するエラー信号生成部を更に備える、ことを特徴とする請求項１または請求項２に記載のＡＰＩリクエスト処理装置とした。
このようにすることで、ＡＰＩ利用装置においてＡＰＩリクエストが完全でなかったことを認識することができる。よって、ＡＰＩ利用装置は、ＡＰＩリクエストの再送信等、意図するリクエストが正常に受領されるように対応することが可能となる。
請求項４に記載の発明は、前記完全性判定部が前記リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定した場合、当該リダイレクトＡＰＩリクエストのデータ長を最大データ長として検出する最大長検出部と、前記最大長検出部で検出された前記最大データ長を前記ＡＰＩ利用装置の識別子とともに記憶する最大長記憶部と、を備え、前記リダイレクト要求部は、前記ＡＰＩ利用装置の前記最大データ長が前記最大長記憶部に記憶された後、次回以降前記ＡＰＩリクエストを受信した場合は、前記リダイレクトＡＰＩリクエストの再送を要求せず、前記完全性判定部は、前記次回以降受信した前記ＡＰＩリクエストのデータ長と前記最大長記憶部に記憶された前記最大データ長とを比較して当該ＡＰＩリクエストのデータ完全性を判定する、ことを特徴とする請求項１から請求項３のいずれか１項に記載のＡＰＩリクエスト処理装置とした。
このようにすることで、同一のＡＰＩ利用装置から次回以降ＡＰＩリクエストを受信した場合は、リダイレクトＡＰＩリクエストの再送を要求しないでＡＰＩリクエストのデータ完全性を判定することができる。よって、ＡＰＩリクエスト処理装置とＡＰＩ利用装置との間のネットワークトラフィックを低減させて、効率的にＡＰＩリクエストを処理することができる。
請求項５に記載の発明は、前記リダイレクト要求部は、前記クエリ文字列の先頭にも所定の前記追加文字列を追加するよう要求し、前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、当該ＡＰＩリクエストの前記クエリ文字列の先頭に前記追加文字列が記載されているか否かに基づいて、当該ＡＰＩリクエストが前記リダイレクトＡＰＩリクエストであるか否かを判定するリクエスト判定部を更に備える、ことを特徴とする請求項１から請求項４のいずれか１項に記載のＡＰＩリクエスト処理装置とした。
このようにすることで、受信したＡＰＩリクエストがリダイレクトされたものであるか否かを容易に判定することができ、効率的にＡＰＩリクエストを処理することができる。
本発明によれば、ＡＰＩ利用装置からのＡＰＩリクエストを処理する際に、不完全なＡＰＩリクエストによるアプリケーションの誤作動を防止する、ＡＰＩリクエスト処理装置、ＡＰＩリクエスト処理方法およびＡＰＩリクエスト処理プログラムを提供することができる。
（実施の形態）
以下に添付図面を参照して、本発明にかかるＡＰＩリクエスト処理装置１０、ＡＰＩリクエスト処理方法およびＡＰＩリクエスト処理プログラムの好適な実施の形態を詳細に説明する。
図１は、実施の形態にかかるＡＰＩリクエスト処理装置１０の構成を示すブロック図である。
ＡＰＩリクエスト処理装置１０は、ＡＰＩ利用装置３０から送信されたＡＰＩリクエストを解析し、ＡＰＩ利用装置３０から要求されている処理を実行する後段装置３２のＡＰＩを決定し、後段装置３２にＡＰＩリクエストを送信する機能を有する。また、ＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストに対応して後段装置３２から送信された出力データを中継し、ＡＰＩ利用装置３０に送信する。
なお、ＡＰＩリクエスト処理装置１０には、複数の後段装置１０が接続されてもよく、その後段装置３２に対応する機能部をＡＰＩリクエスト処理装置１０内に有していてもよい。
また、ＡＰＩリクエスト処理装置１０には、複数のＡＰＩ利用装置３０が接続されていてもよい。この場合、複数のＡＰＩ利用装置３０のそれぞれをＡＰＩ利用装置３０の識別子（ＩＰアドレス、ＡＰＩサービスのクライアントＩＤ、ＡＰＩキー等）により識別する。
以下に添付図面を参照して、本発明にかかるＡＰＩリクエスト処理装置１０、ＡＰＩリクエスト処理方法およびＡＰＩリクエスト処理プログラムの好適な実施の形態を詳細に説明する。
図１は、実施の形態にかかるＡＰＩリクエスト処理装置１０の構成を示すブロック図である。
ＡＰＩリクエスト処理装置１０は、ＡＰＩ利用装置３０から送信されたＡＰＩリクエストを解析し、ＡＰＩ利用装置３０から要求されている処理を実行する後段装置３２のＡＰＩを決定し、後段装置３２にＡＰＩリクエストを送信する機能を有する。また、ＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストに対応して後段装置３２から送信された出力データを中継し、ＡＰＩ利用装置３０に送信する。
なお、ＡＰＩリクエスト処理装置１０には、複数の後段装置１０が接続されてもよく、その後段装置３２に対応する機能部をＡＰＩリクエスト処理装置１０内に有していてもよい。
また、ＡＰＩリクエスト処理装置１０には、複数のＡＰＩ利用装置３０が接続されていてもよい。この場合、複数のＡＰＩ利用装置３０のそれぞれをＡＰＩ利用装置３０の識別子（ＩＰアドレス、ＡＰＩサービスのクライアントＩＤ、ＡＰＩキー等）により識別する。
ＡＰＩリクエスト処理装置１０は、リダイレクト要求部１２、完全性判定部１４、リクエスト判定部１６、設定受付部１８、設定記憶部２０、最大長検出部２２、最大長記憶部２４、エラー信号生成部２６、ＡＰＩレスポンス処理部２８を備える。
まず、各機能部の概要について説明する。
リダイレクト要求部１２（リダイレクト要求手段）は、ＡＰＩリクエストの送信元のＡＰＩ利用装置３０に対するリダイレクト要求を生成し、ＡＰＩレスポンス処理部２８に送信処理を依頼する。
完全性判定部１４（完全性判定手段）は、ＡＰＩリクエストのデータ完全性を保証できるか否かを判定する。
リクエスト判定部１６は、受信したＡＰＩリクエストを、リダイレクト要求部１２または完全性判定部１４のいずれに引き渡すかを判定する。
リダイレクト要求部１２（リダイレクト要求手段）は、ＡＰＩリクエストの送信元のＡＰＩ利用装置３０に対するリダイレクト要求を生成し、ＡＰＩレスポンス処理部２８に送信処理を依頼する。
完全性判定部１４（完全性判定手段）は、ＡＰＩリクエストのデータ完全性を保証できるか否かを判定する。
リクエスト判定部１６は、受信したＡＰＩリクエストを、リダイレクト要求部１２または完全性判定部１４のいずれに引き渡すかを判定する。
設定受付部１８は、キーボード等の入力デバイスである設定入力装置３４とＡＰＩリクエスト処理装置１０とのインターフェースであり、設定入力装置３４を介した文字列（後述する追加文字列）の入力を受け付ける。
設定記憶部２０は、設定受付部１８で受け付けた文字列（後述する追加文字列）を記憶する。
設定記憶部２０は、設定受付部１８で受け付けた文字列（後述する追加文字列）を記憶する。
最大長検出部２２は、ＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長（ＵＲＬ最大長）を検出する。
最大長記憶部２４は、最大長検出部２２で検出された最大データ長をＡＰＩ利用装置３０の識別子とともに記憶する。
エラー信号生成部２６は、完全性判定部１４からの依頼を受け、ＡＰＩ利用装置３０に送信するエラー信号を生成する。
ＡＰＩレスポンス処理部２８は、ＡＰＩ利用装置３０に対してＡＰＩリクエスト処理装置１０側からの応答データ（後段装置３２の出力データを含む）を送信する。
最大長記憶部２４は、最大長検出部２２で検出された最大データ長をＡＰＩ利用装置３０の識別子とともに記憶する。
エラー信号生成部２６は、完全性判定部１４からの依頼を受け、ＡＰＩ利用装置３０に送信するエラー信号を生成する。
ＡＰＩレスポンス処理部２８は、ＡＰＩ利用装置３０に対してＡＰＩリクエスト処理装置１０側からの応答データ（後段装置３２の出力データを含む）を送信する。
つぎに、各機能部の詳細について説明する。
リダイレクト要求部１２（リダイレクト要求手段）は、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合に、ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するようＡＰＩ利用装置３０に要求する。
本実施の形態では、リダイレクト要求部１２は、クエリ文字列の前後にそれぞれ異なる追加文字列（先頭用追加文字列および末尾用追加文字列）を追加するよう要求する。
すなわち、リダイレクト要求部１２は、ＡＰＩリクエストのＵＲＬで指定されたクエリ文字列の前後に所定の追加文字列を追加したものを、新たなクエリ文字列として送信し直すよう要求するリダイレクト信号を生成する。
リダイレクト要求部１２（リダイレクト要求手段）は、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合に、ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するようＡＰＩ利用装置３０に要求する。
本実施の形態では、リダイレクト要求部１２は、クエリ文字列の前後にそれぞれ異なる追加文字列（先頭用追加文字列および末尾用追加文字列）を追加するよう要求する。
すなわち、リダイレクト要求部１２は、ＡＰＩリクエストのＵＲＬで指定されたクエリ文字列の前後に所定の追加文字列を追加したものを、新たなクエリ文字列として送信し直すよう要求するリダイレクト信号を生成する。
より詳細には、リダイレクト要求部１２は、設定記憶部２０に記憶されている追加文字列を読み出し、ＡＰＩリクエスト中のクエリ文字列の前後に追加文字列を挿入して新たなクエリ文字列を生成する。そして、この新たなクエリ文字列を含むリダイレクトＡＰＩリクエストの再送を要求するリダイレクト信号を生成する。
生成されたリダイレクト信号は、ＡＰＩレスポンス処理部２８によってＡＰＩ利用装置３０に送信される。
生成されたリダイレクト信号は、ＡＰＩレスポンス処理部２８によってＡＰＩ利用装置３０に送信される。
図３は、設定記憶部２０に記憶された追加文字列の一例を示す説明図である。
図３に示す追加文字列データベース１では、クエリ文字列の先頭に追加する先頭用追加文字列が「＿ｂｅｇｉｎ」、クエリ文字列の末尾に追加する末尾用追加文字列が「＿ｅｎｄ」となっている。
先頭用追加文字列および末尾用追加文字列として指定する文字の配列は、通常ＡＰＩで用いられるパラメータ等と重複しなければ、すなわち、先頭用追加文字列または末尾用追加文字列として他のパラメータと識別できる文字列であれば、特に制限はない。また、先頭用追加文字列と末尾用追加文字列とが同一の文字列であってもよい。
図３に示す追加文字列データベース１では、クエリ文字列の先頭に追加する先頭用追加文字列が「＿ｂｅｇｉｎ」、クエリ文字列の末尾に追加する末尾用追加文字列が「＿ｅｎｄ」となっている。
先頭用追加文字列および末尾用追加文字列として指定する文字の配列は、通常ＡＰＩで用いられるパラメータ等と重複しなければ、すなわち、先頭用追加文字列または末尾用追加文字列として他のパラメータと識別できる文字列であれば、特に制限はない。また、先頭用追加文字列と末尾用追加文字列とが同一の文字列であってもよい。
図２（ａ）に、ＡＰＩ利用装置３０のＡＰＩリクエストの一例を示す。
図２（ａ）のＡＰＩリクエストは、ホスト（Ｈｏｓｔ）：ａｐｉ．ｅｘａｍｐｌｅ．ｃｏｍに対して、ＡＰＩ名：ａｐｉＡを用いて、「？」以下に記載されているクエリパラメータで指定した条件を満たす情報を要求するものである。
１行目には、クエリパラメータが複数指定（ｐａｒａｍ１、ｐａｒａｍ１００等）されている。ＨＴＴＰのバージョンは１．１である。
このようなＡＰＩリクエストのうち、「ｐａｒａｍ１＝ａａａ＆（中略）＆ｐａｒａｍ１００＝ｚｚｚ」までがクエリ文字列である。
図２（ａ）のＡＰＩリクエストは、ホスト（Ｈｏｓｔ）：ａｐｉ．ｅｘａｍｐｌｅ．ｃｏｍに対して、ＡＰＩ名：ａｐｉＡを用いて、「？」以下に記載されているクエリパラメータで指定した条件を満たす情報を要求するものである。
１行目には、クエリパラメータが複数指定（ｐａｒａｍ１、ｐａｒａｍ１００等）されている。ＨＴＴＰのバージョンは１．１である。
このようなＡＰＩリクエストのうち、「ｐａｒａｍ１＝ａａａ＆（中略）＆ｐａｒａｍ１００＝ｚｚｚ」までがクエリ文字列である。
図２（ｂ）は、図２（ａ）のＡＰＩリクエストに対するリダイレクト信号の一例である。
１行目にはＡＰＩリクエストの再送信を要求するステータスコードが記載され、２行目に再送信時のＵＲＬが記載されている。
２行目のＵＲＬのクエリ文字列の先頭には先頭用追加文字列「＿ｂｅｇｉｎ」が、末尾には末尾用追加文字列を「＿ｅｎｄ」が、それぞれ挿入されている。
１行目にはＡＰＩリクエストの再送信を要求するステータスコードが記載され、２行目に再送信時のＵＲＬが記載されている。
２行目のＵＲＬのクエリ文字列の先頭には先頭用追加文字列「＿ｂｅｇｉｎ」が、末尾には末尾用追加文字列を「＿ｅｎｄ」が、それぞれ挿入されている。
図２（ｃ）は、図２（ｂ）のリダイレクト信号を受けてＡＰＩ利用装置３０が再送したＡＰＩリクエスト（以下、「リダイレクトＡＰＩリクエスト」という）の一例である。
図２（ｃ）のリダイレクトＡＰＩリクエストには、クエリ文字列の先頭および末尾に先頭用追加文字列「＿ｂｅｇｉｎ」および末尾用追加文字列を「＿ｅｎｄ」がそれぞれ含まれている。
図２（ｃ）のリダイレクトＡＰＩリクエストには、クエリ文字列の先頭および末尾に先頭用追加文字列「＿ｂｅｇｉｎ」および末尾用追加文字列を「＿ｅｎｄ」がそれぞれ含まれている。
リダイレクトＡＰＩリクエストを受信した場合には、完全性判定部１４で処理を行う。
なお、受信したＡＰＩリクエストが通常の（追加文字列が追加されていない）ＡＰＩリクエストであるか、リダイレクトＡＰＩリクエストであるかは、リクエスト判定部１６が判定する。
なお、受信したＡＰＩリクエストが通常の（追加文字列が追加されていない）ＡＰＩリクエストであるか、リダイレクトＡＰＩリクエストであるかは、リクエスト判定部１６が判定する。
リクエスト判定部１６は、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合、当該ＡＰＩリクエストのクエリ文字列の先頭に追加文字列（先頭用追加文字列）が記載されているか否かに基づいて、当該ＡＰＩリクエストがリダイレクトＡＰＩリクエストであるか否かを判定する。
すなわち、リクエスト判定部１６は、受信したＡＰＩリクエストのクエリ文字列の先頭に先頭用追加文字列が記載されている場合にはリダイレクトＡＰＩリクエストであると判定して、完全性判定部１４に処理を依頼する。一方、クエリ文字列の先頭に先頭用追加文字列が記載されていない場合には通常のＡＰＩリクエストであると判定して、リダイレクト要求部１２に処理を依頼する。
すなわち、リクエスト判定部１６は、受信したＡＰＩリクエストのクエリ文字列の先頭に先頭用追加文字列が記載されている場合にはリダイレクトＡＰＩリクエストであると判定して、完全性判定部１４に処理を依頼する。一方、クエリ文字列の先頭に先頭用追加文字列が記載されていない場合には通常のＡＰＩリクエストであると判定して、リダイレクト要求部１２に処理を依頼する。
完全性判定部１４（完全性判定手段）は、リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれるクエリ文字列の末尾に追加文字列（末尾用追加文字列）が記載されているか否かに基づいて、ＡＰＩリクエストのデータ完全性を判定する。
ここで、ＡＰＩリクエストのデータ完全性とは、ＡＰＩ利用装置３０のユーザが意図した要求の内容（クエリ文字列等）が全てＡＰＩリクエストに含まれているか否かである。
ＡＰＩリクエストのデータ長（バイト数）は、主にクエリ文字列の長さによって変化するが、ＡＰＩ利用装置３０において処理可能なＡＰＩリクエストの最大データ長（ＵＲＬ最大長）が決まっている場合、最大データ長を超える部分の文字列が削除されて不完全な形でＡＰＩリクエストが送信される可能性がある。
完全性判定部１４は、このようなデータ長の超過によってＡＰＩリクエストが不完全な形となっていないかを監視する。
なお、ＡＰＩリクエストのデータ長は、例えばＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計したＵＲＬ長をカウントする。
ここで、ＡＰＩリクエストのデータ完全性とは、ＡＰＩ利用装置３０のユーザが意図した要求の内容（クエリ文字列等）が全てＡＰＩリクエストに含まれているか否かである。
ＡＰＩリクエストのデータ長（バイト数）は、主にクエリ文字列の長さによって変化するが、ＡＰＩ利用装置３０において処理可能なＡＰＩリクエストの最大データ長（ＵＲＬ最大長）が決まっている場合、最大データ長を超える部分の文字列が削除されて不完全な形でＡＰＩリクエストが送信される可能性がある。
完全性判定部１４は、このようなデータ長の超過によってＡＰＩリクエストが不完全な形となっていないかを監視する。
なお、ＡＰＩリクエストのデータ長は、例えばＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計したＵＲＬ長をカウントする。
より詳細には、完全性判定部１４は、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に追加文字列（末尾用追加文字列）が記載されている場合には、リダイレクトＡＰＩリクエストのデータ長がＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長以内であり、リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定する。
また、クエリ文字列の末尾に追加文字列が記載されていない場合には、ＡＰＩリクエストのデータ長が最大データ長を超えており、リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定する。
また、クエリ文字列の末尾に追加文字列が記載されていない場合には、ＡＰＩリクエストのデータ長が最大データ長を超えており、リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定する。
完全性判定部１４は、リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定した場合には、リダイレクトＡＰＩリクエストで要求されているＡＰＩを提供する後段装置３２に対してリダイレクトＡＰＩリクエストを転送する。
図２（ｄ）は、後段装置３２に対してリダイレクトＡＰＩリクエストが転送された場合に、後段装置３２が送信する提供データ（正常レスポンス）の一例である。
ヘッダ１行目はＡＰＩリクエストの要求が成功したことを示し、ボディ部にリクエストに応じた情報が返される。
図２（ｄ）は、後段装置３２に対してリダイレクトＡＰＩリクエストが転送された場合に、後段装置３２が送信する提供データ（正常レスポンス）の一例である。
ヘッダ１行目はＡＰＩリクエストの要求が成功したことを示し、ボディ部にリクエストに応じた情報が返される。
また、完全性判定部１４は、リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定した場合には、エラー信号生成部２６にエラー信号の生成を依頼する。
エラー信号生成部２６は、ＡＰＩ利用装置３０に送信するエラー信号を生成し、エラー信号をＡＰＩ利用装置３０に送信するようＡＰＩレスポンス処理部２８に依頼する。
図２（ｅ）は、エラー信号（エラーレスポンス）の一例である。
ヘッダ部の１行目はＡＰＩリクエストが不正であることを示し、ボディ部にＵＲＬのデータ長が最大値を超えている旨のエラーメッセージが記載されている。
エラー信号を受信したＡＰＩ利用装置３０は、例えば自装置で処理可能なＡＰＩリクエストの最大データ長以内にＡＰＩリクエストを変更し、再度ＡＰＩリクエスト処理装置１０に送信する。
エラー信号生成部２６は、ＡＰＩ利用装置３０に送信するエラー信号を生成し、エラー信号をＡＰＩ利用装置３０に送信するようＡＰＩレスポンス処理部２８に依頼する。
図２（ｅ）は、エラー信号（エラーレスポンス）の一例である。
ヘッダ部の１行目はＡＰＩリクエストが不正であることを示し、ボディ部にＵＲＬのデータ長が最大値を超えている旨のエラーメッセージが記載されている。
エラー信号を受信したＡＰＩ利用装置３０は、例えば自装置で処理可能なＡＰＩリクエストの最大データ長以内にＡＰＩリクエストを変更し、再度ＡＰＩリクエスト処理装置１０に送信する。
また、完全性判定部１４は、最大長検出部２２にＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長の検出を依頼する。
最大長検出部２２は、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に追加文字列が記載されているか否かを判断し、追加文字列が記載されていない場合（データ完全性が保証できない場合）には、当該リダイレクトＡＰＩリクエストのデータ長を、ＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長として検出する。
また、追加文字列が記載されている場合（データ完全性が保証できる場合）には、ＡＰＩ利用装置３０の最大データ長を「上限なし」と検出する。
最大長検出部２２で検出された最大データ長は、ＡＰＩ利用装置３０の識別子とともに最大長記憶部２４で記憶される。
最大長検出部２２は、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に追加文字列が記載されているか否かを判断し、追加文字列が記載されていない場合（データ完全性が保証できない場合）には、当該リダイレクトＡＰＩリクエストのデータ長を、ＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長として検出する。
また、追加文字列が記載されている場合（データ完全性が保証できる場合）には、ＡＰＩ利用装置３０の最大データ長を「上限なし」と検出する。
最大長検出部２２で検出された最大データ長は、ＡＰＩ利用装置３０の識別子とともに最大長記憶部２４で記憶される。
図４は、最大長記憶部２４に記憶された最大データ長の一例を示す説明図である。
図４の最大データ長データベース２は、ＡＰＩ利用装置３０の識別子種別、識別子値および最大データ長（ＵＲＬ最大長）を、それぞれ関連付けて記憶している。
識別子種別は、例えばＩＰアドレス、ＡＰＩサービスのクライアントＩＤ、ＡＰＩキー等である。
また、最大データ長は例えばＡＰＩリクエストのバイト数で表現される。
なお、ＡＰＩ利用装置３０で稼働する複数のアプリケーションでそれぞれＡＰＩを使用する場合、それぞれのアプリケーションで処理可能な最大データ長が異なる場合がある。この場合には、それぞれのアプリケーションに対して異なる識別子を付加して識別可能としてもよい。
図４の最大データ長データベース２は、ＡＰＩ利用装置３０の識別子種別、識別子値および最大データ長（ＵＲＬ最大長）を、それぞれ関連付けて記憶している。
識別子種別は、例えばＩＰアドレス、ＡＰＩサービスのクライアントＩＤ、ＡＰＩキー等である。
また、最大データ長は例えばＡＰＩリクエストのバイト数で表現される。
なお、ＡＰＩ利用装置３０で稼働する複数のアプリケーションでそれぞれＡＰＩを使用する場合、それぞれのアプリケーションで処理可能な最大データ長が異なる場合がある。この場合には、それぞれのアプリケーションに対して異なる識別子を付加して識別可能としてもよい。
最大長記憶部２４を用いることによって、次回以降のＡＰＩリクエスト送信時の処理を効率的に行うことができる。
例えば、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合、リクエスト判定部１６は、当該ＡＰＩ利用装置３０の最大データ長が最大長記憶部２４に記憶されているか否かを判定する。
最大データ長が最大長記憶部２４に記憶されていない場合には、ＡＰＩリクエストをリダイレクト要求部１２に引き渡し、リダイレクト信号の送信を依頼する。
また、最大データ長が最大長記憶部２４に記憶されている場合には、ＡＰＩリクエストを完全性判定部１４に引き渡し、データ完全性の判定を依頼する。完全性判定部１４では、最大長記憶部２４に記憶された最大データ長と今回受信したＡＰＩリクエストのデータ長とを比較してデータ完全性を判定する。
例えば、ＡＰＩ利用装置３０からＡＰＩリクエストを受信した場合、リクエスト判定部１６は、当該ＡＰＩ利用装置３０の最大データ長が最大長記憶部２４に記憶されているか否かを判定する。
最大データ長が最大長記憶部２４に記憶されていない場合には、ＡＰＩリクエストをリダイレクト要求部１２に引き渡し、リダイレクト信号の送信を依頼する。
また、最大データ長が最大長記憶部２４に記憶されている場合には、ＡＰＩリクエストを完全性判定部１４に引き渡し、データ完全性の判定を依頼する。完全性判定部１４では、最大長記憶部２４に記憶された最大データ長と今回受信したＡＰＩリクエストのデータ長とを比較してデータ完全性を判定する。
すなわち、最大長記憶部２４を設けた場合、リダイレクト要求部１２は、ＡＰＩ利用装置３０の最大データ長が最大長記憶部２４に記憶された後、次回以降にＡＰＩリクエストを受信した場合、リダイレクトＡＰＩリクエストの再送を要求しない。完全性判定部１４は、次回以降に受信したＡＰＩリクエストのデータ長と最大長記憶部２４に記憶された最大データ長とを比較して当該ＡＰＩリクエストのデータ完全性を判定することが可能となる。
これにより、次回以降のＡＰＩリクエスト時のネットワークトラフィックを、初回のＡＰＩリクエスト時と比較して半減させて、効率的にＡＰＩリクエストを処理することができる。
これにより、次回以降のＡＰＩリクエスト時のネットワークトラフィックを、初回のＡＰＩリクエスト時と比較して半減させて、効率的にＡＰＩリクエストを処理することができる。
図５は、ＡＰＩリクエスト処理装置１０におけるＡＰＩリクエスト処理手順を示すフローチャートである。
ＡＰＩリクエスト処理装置１０は、まずＡＰＩリクエストの受信に先立って、設定受付部１８により追加文字列（先頭用追加文字列および末尾用追加文字列）の設定を受け付け、設定記憶部２０に記憶しておく（ステップＳ５００）。そして、ＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストを受信する度に、ステップＳ５０２以降の処理を実行する。
ＡＰＩリクエスト処理装置１０は、まずＡＰＩリクエストの受信に先立って、設定受付部１８により追加文字列（先頭用追加文字列および末尾用追加文字列）の設定を受け付け、設定記憶部２０に記憶しておく（ステップＳ５００）。そして、ＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストを受信する度に、ステップＳ５０２以降の処理を実行する。
ＡＰＩ利用装置３０からＡＰＩリクエストを受信すると（ステップＳ５０２）、リクエスト判定部１６は、ＡＰＩリクエストに含まれるＡＰＩ利用装置３０の識別子を用いて最大長記憶部２４のデータベース（図４の最大データ長データベース２）を参照し、当該ＡＰＩ利用装置３０の最大データ長が記憶されており、かつ、その最大データ長が「上限なし」以外のデータであるかを判断する（ステップＳ５０４）。
最大データ長が記憶されており、かつ、そのデータが「上限なし」以外である場合（ステップＳ５０４：Ｙｅｓ）、リクエスト判定部１６は、ＡＰＩリクエストを完全性判定部１４に引き渡す。
完全性判定部１４は、ＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計したＵＲＬ長を、ＡＰＩリクエストのデータ長として算出する。そして、算出したＡＰＩリクエストのデータ長が最大長記憶部２４に記憶された最大データ長を超えているか否かを判断する（ステップＳ５０６）。
完全性判定部１４は、ＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計したＵＲＬ長を、ＡＰＩリクエストのデータ長として算出する。そして、算出したＡＰＩリクエストのデータ長が最大長記憶部２４に記憶された最大データ長を超えているか否かを判断する（ステップＳ５０６）。
ＡＰＩリクエストのデータ長が最大データ長を超えている場合（ステップＳ５０６：Ｙｅｓ）、完全性判定部１４はＡＰＩリクエストのデータ完全性を保証できないと判断し、エラー信号生成部２６にエラー信号の生成を依頼する。エラー信号生成部２６は、ＡＰＩ利用装置３０宛のエラー信号を生成し、ＡＰＩレスポンス処理部２８を介してエラー信号をＡＰＩ利用装置３０に送信して（ステップＳ５０８）、本フローチャートによる処理を終了する。
一方、ＡＰＩリクエストのデータ長が最大データ長を超えていない場合（ステップＳ５０６：Ｎｏ）、完全性判定部１４はＡＰＩリクエストのデータ完全性を保証できると判断し、後段装置３２にＡＰＩリクエストを送信して（ステップＳ５１０）、本フローチャートによる処理を終了する。
一方、ＡＰＩリクエストのデータ長が最大データ長を超えていない場合（ステップＳ５０６：Ｎｏ）、完全性判定部１４はＡＰＩリクエストのデータ完全性を保証できると判断し、後段装置３２にＡＰＩリクエストを送信して（ステップＳ５１０）、本フローチャートによる処理を終了する。
また、ステップＳ５０４において、最大データ長が記憶されていない場合、または、最大データ長のデータが「上限なし」の場合には（ステップＳ５０４：Ｎｏ）、リクエスト判定部１６は、設定記憶部２０から先頭用追加文字列を読み出し、ＡＰＩリクエストのクエリ文字列の先頭に先頭用追加文字列が記載されているか否かを判断する（ステップＳ５１２）。
先頭用追加文字列が含まれていない場合（ステップＳ５１２：Ｎｏ）、リクエスト判定部１６は、本ＡＰＩリクエストがリダイレクトＡＰＩリクエストではないと判定し、ＡＰＩリクエストをリダイレクト要求部１２に引き渡す。
リダイレクト要求部１２は、設定記憶部２０（図３の追加文字列データベース１）に記憶されている追加文字列を読み出し、クエリ文字列の前後に追加文字列を挿入したリダイレクトＡＰＩリクエストの再送を要求するリダイレクト信号を生成し、ＡＰＩレスポンス処理部２８を介してＡＰＩ利用装置３０に送信して（ステップＳ５１４）、本フローチャートによる処理を終了する。
先頭用追加文字列が含まれていない場合（ステップＳ５１２：Ｎｏ）、リクエスト判定部１６は、本ＡＰＩリクエストがリダイレクトＡＰＩリクエストではないと判定し、ＡＰＩリクエストをリダイレクト要求部１２に引き渡す。
リダイレクト要求部１２は、設定記憶部２０（図３の追加文字列データベース１）に記憶されている追加文字列を読み出し、クエリ文字列の前後に追加文字列を挿入したリダイレクトＡＰＩリクエストの再送を要求するリダイレクト信号を生成し、ＡＰＩレスポンス処理部２８を介してＡＰＩ利用装置３０に送信して（ステップＳ５１４）、本フローチャートによる処理を終了する。
一方、ステップＳ５１２で先頭用追加文字列が含まれている場合（ステップＳ５１２：Ｙｅｓ）、リクエスト判定部１６は、本ＡＰＩリクエストがリダイレクトＡＰＩリクエストであると判定し、リダイレクトＡＰＩリクエストを完全性判定部１４に引き渡す。
完全性判定部１４は、設定記憶部２０から末尾用追加文字列を読み出し、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に、末尾用追加文字列が記載されているか否かを判断する（ステップＳ５１６）。
末尾用追加文字列が記載されている場合（ステップＳ５１６：Ｙｅｓ）、完全性判定部１４は、リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定し、後段装置３２にＡＰＩリクエストを送信する（ステップＳ５１８）。
また、最大長検出部２２は、今回のＡＰＩリクエストの送信元であるＡＰＩ利用装置３０の最大データ長を「上限なし」と検出し、当該ＡＰＩ利用装置３０の識別情報とともに最大長記憶部２４（図４の最大データ長データベース２）に記憶して（ステップＳ５２０）、本フローチャートによる処理を終了する。
完全性判定部１４は、設定記憶部２０から末尾用追加文字列を読み出し、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に、末尾用追加文字列が記載されているか否かを判断する（ステップＳ５１６）。
末尾用追加文字列が記載されている場合（ステップＳ５１６：Ｙｅｓ）、完全性判定部１４は、リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定し、後段装置３２にＡＰＩリクエストを送信する（ステップＳ５１８）。
また、最大長検出部２２は、今回のＡＰＩリクエストの送信元であるＡＰＩ利用装置３０の最大データ長を「上限なし」と検出し、当該ＡＰＩ利用装置３０の識別情報とともに最大長記憶部２４（図４の最大データ長データベース２）に記憶して（ステップＳ５２０）、本フローチャートによる処理を終了する。
また、ステップＳ５１６で末尾用追加文字列が記載されていない場合（ステップＳ５１６：Ｎｏ）、完全性判定部１４は、リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定し、エラー信号生成部２６にエラー信号の生成を依頼する。エラー信号生成部２６は、ＡＰＩ利用装置３０宛のエラー信号の生成し、ＡＰＩレスポンス処理部２８を介してエラー信号をＡＰＩ利用装置３０に送信する（ステップＳ５２２）。
また、最大長検出部２２は、今回のリダイレクトＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計し、その合計値をＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長として検出する。そして、ＡＰＩ利用装置３０の識別情報と最大データ長とを関連付けて最大長記憶部２４（図４の最大データ長データベース２）に記憶して（ステップＳ５２４）、本フローチャートによる処理を終了する。
また、最大長検出部２２は、今回のリダイレクトＡＰＩリクエストに含まれるホスト名、パス、クエリ文字列等の長さを合計し、その合計値をＡＰＩ利用装置３０で処理可能なＡＰＩリクエストの最大データ長として検出する。そして、ＡＰＩ利用装置３０の識別情報と最大データ長とを関連付けて最大長記憶部２４（図４の最大データ長データベース２）に記憶して（ステップＳ５２４）、本フローチャートによる処理を終了する。
以上説明したように、実施の形態にかかるＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストを受信した際に、ＡＰＩリクエストに含まれるクエリ文字列の末尾に追加文字列を追加してリダイレクトするように要求するので、ＡＰＩリクエストを処理する際にＡＰＩリクエストのデータが完全な形で受信できているか否かを判定することができる。よって、ＡＰＩ利用装置３０のユーザが意図しない不完全なＡＰＩリクエストによる処理を実行することを防止し、ＡＰＩリクエスト処理装置１０を介した処理の信頼性を向上させることができる。
また、ＡＰＩリクエスト処理装置１０は、リダイレクトＡＰＩリクエストのクエリ文字列の末尾に追加文字列が記載されているか否かを判定するのみでリダイレクトＡＰＩリクエストのデータ完全性を判定することができ、効率的に判定処理を実行することができる。
また、ＡＰＩリクエスト処理装置１０は、ＡＰＩリクエストのデータ完全性が保証されていない場合に、ＡＰＩ利用装置３０にエラー信号を送信するので、ＡＰＩ利用装置３０においてＡＰＩリクエストが完全でなかったことを認識することができ、ＡＰＩ利用装置３０は、ＡＰＩリクエストの再送信等、意図するリクエストが正常に受領されるように対応することが可能となる。
また、ＡＰＩリクエスト処理装置１０は、ＡＰＩ利用装置３０ごとの最大データ長を記憶しておくので、同一のＡＰＩ利用装置３０から次回以降ＡＰＩリクエストを受信した場合は、リダイレクトＡＰＩリクエストの再送を要求しないでＡＰＩリクエストのデータ完全性を判定することができ、ＡＰＩリクエスト処理装置１０とＡＰＩ利用装置３０との間のネットワークトラフィックを低減させて、効率的にＡＰＩリクエストを処理することができる。
また、ＡＰＩリクエスト処理装置１０は、クエリ文字列の先頭にも追加文字列を追加するよう要求し、当該先頭の追加文字列を用いて受信したＡＰＩリクエストがリダイレクトＡＰＩリクエストであるか否かを判定するので、ＡＰＩリクエストがリダイレクトされたものであるか否かを容易に判定することができ、効率的にＡＰＩリクエストを処理することができる。
１ 追加文字列データベース
２ 最大データ長データベース
１０ ＡＰＩリクエスト処理装置
１２ リダイレクト要求部（リダイレクト要求手段）
１４ 完全性判定部（完全性判定手段）
１６ リクエスト判定部
１８ 設定受付部
２０ 設定記憶部
２２ 最大長検出部
２４ 最大長記憶部
２６ エラー信号生成部
２８ ＡＰＩレスポンス処理部
３０ ＡＰＩ利用装置
３２ 後段装置
３４ 設定入力装置
２ 最大データ長データベース
１０ ＡＰＩリクエスト処理装置
１２ リダイレクト要求部（リダイレクト要求手段）
１４ 完全性判定部（完全性判定手段）
１６ リクエスト判定部
１８ 設定受付部
２０ 設定記憶部
２２ 最大長検出部
２４ 最大長記憶部
２６ エラー信号生成部
２８ ＡＰＩレスポンス処理部
３０ ＡＰＩ利用装置
３２ 後段装置
３４ 設定入力装置
Claims (7)
- ＡＰＩ利用装置からのＡＰＩリクエストを処理するＡＰＩリクエスト処理装置であって、
前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するリダイレクト要求部と、
前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定する完全性判定部と、
を備えることを特徴とするＡＰＩリクエスト処理装置。 - 前記リダイレクト要求部は、前記クエリ文字列の末尾に前記追加文字列を追加するよう要求し、
前記完全性判定部は、前記クエリ文字列の末尾に前記追加文字列が記載されている場合には、前記リダイレクトＡＰＩリクエストのデータ長が前記ＡＰＩ利用装置で処理可能な前記ＡＰＩリクエストの最大データ長以内であり、前記リダイレクトＡＰＩリクエストのデータ完全性を保証できると判定し、前記クエリ文字列の末尾に前記追加文字列が記載されていない場合には、前記リダイレクトＡＰＩリクエストのデータ長が前記最大データ長を超えており、前記リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定する、
ことを特徴とする請求項１に記載のＡＰＩリクエスト処理装置。 - 前記完全性判定部が前記リダイレクトＡＰＩリクエストのデータ完全性を保証できないと判定した場合、前記ＡＰＩ利用装置にエラー信号を送信するエラー信号生成部を更に備える、
ことを特徴とする請求項１または請求項２に記載のＡＰＩリクエスト処理装置。 - 前記完全性判定部が前記リダイレクトＡＰＩリクエストのデータ完全性を保証できない判定した場合、当該リダイレクトＡＰＩリクエストのデータ長を最大データ長として検出する最大長検出部と、
前記最大長検出部で検出された前記最大データ長を前記ＡＰＩ利用装置の識別子とともに記憶する最大長記憶部と、を備え、
前記リダイレクト要求部は、前記ＡＰＩ利用装置の前記最大データ長が前記最大長記憶部に記憶された後、次回以降前記ＡＰＩリクエストを受信した場合は、前記リダイレクトＡＰＩリクエストの再送を要求せず、
前記完全性判定部は、前記次回以降受信した前記ＡＰＩリクエストのデータ長と前記最大長記憶部に記憶された前記最大データ長とを比較して当該ＡＰＩリクエストのデータ完全性を判定する、
ことを特徴とする請求項１から請求項３のいずれか１項に記載のＡＰＩリクエスト処理装置。 - 前記リダイレクト要求部は、前記クエリ文字列の先頭にも前記追加文字列を追加するよう要求し、
前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、当該ＡＰＩリクエストの前記クエリ文字列の先頭に前記追加文字列が記載されているか否かに基づいて、当該ＡＰＩリクエストが前記リダイレクトＡＰＩリクエストであるか否かを判定するリクエスト判定部を更に備える、
ことを特徴とする請求項１から請求項４のいずれか１に項記載のＡＰＩリクエスト処理装置。 - ＡＰＩ利用装置からのＡＰＩリクエストを処理するＡＰＩリクエスト処理装置のＡＰＩリクエスト処理方法であって、
前記ＡＰＩリクエスト処理装置は、
前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するステップと、
前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定するステップと、
を実行することを特徴とするＡＰＩリクエスト処理方法。 - ＡＰＩ利用装置からのＡＰＩリクエストを処理するコンピュータを、
前記ＡＰＩ利用装置から前記ＡＰＩリクエストを受信した場合、前記ＡＰＩリクエストに含まれるクエリ文字列に所定の追加文字列を追加したリダイレクトＡＰＩリクエストを再送するよう前記ＡＰＩ利用装置に要求するリダイレクト要求手段、
前記リダイレクトＡＰＩリクエストを受信した場合、当該リダイレクトＡＰＩリクエストに含まれる前記クエリ文字列に前記追加文字列が記載されているか否かに基づいて、前記リダイレクトＡＰＩリクエストのデータ完全性を判定する完全性判定手段、
として機能させるためのＡＰＩリクエスト処理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015151548A JP2017033221A (ja) | 2015-07-31 | 2015-07-31 | Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015151548A JP2017033221A (ja) | 2015-07-31 | 2015-07-31 | Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2017033221A true JP2017033221A (ja) | 2017-02-09 |
Family
ID=57988909
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015151548A Pending JP2017033221A (ja) | 2015-07-31 | 2015-07-31 | Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2017033221A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11429688B2 (en) | 2020-03-19 | 2022-08-30 | International Business Machines Corporation | Correcting a URL within a REST API call |
| JP2022157254A (ja) * | 2021-03-31 | 2022-10-14 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 分析装置、分析方法及び分析プログラム |
-
2015
- 2015-07-31 JP JP2015151548A patent/JP2017033221A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11429688B2 (en) | 2020-03-19 | 2022-08-30 | International Business Machines Corporation | Correcting a URL within a REST API call |
| JP2022157254A (ja) * | 2021-03-31 | 2022-10-14 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 分析装置、分析方法及び分析プログラム |
| JP7157200B1 (ja) | 2021-03-31 | 2022-10-19 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 分析装置、分析方法及び分析プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7702917B2 (en) | Data transfer using hyper-text transfer protocol (HTTP) query strings | |
| US9471646B2 (en) | Method and server device for exchanging information items with a plurality of client entities | |
| US20090262724A1 (en) | Proxy server, communication system, communication method and program | |
| KR101201140B1 (ko) | 요구-응답 전송 프로토콜들에 의한 신뢰성 있는 단방향메시징 | |
| JP2017529793A5 (ja) | ||
| JP6279938B2 (ja) | 接続管理装置、通信システム、接続管理方法およびプログラム | |
| KR20140009931A (ko) | 컨텐츠 이름 기반의 컨텐츠 중심 네트워크에서 컨텐츠 및 실시간 스트리밍 컨텐츠 제공을 위한 컨텐츠 요청자 및 컨텐츠 제공자의 통신 방법 | |
| WO2012034518A1 (zh) | 一种提供包含网页地址的消息的方法和系统 | |
| CN112383612B (zh) | 一种文件传输方法、装置、设备及可读存储介质 | |
| JP2017033221A (ja) | Ａｐｉリクエスト処理装置、ａｐｉリクエスト処理方法およびａｐｉリクエスト処理プログラム | |
| US10554723B2 (en) | HTTP server, method for controlling the same, and image forming apparatus | |
| CN109039687A (zh) | 请求的负载均衡方法、装置、系统、设备以及存储介质 | |
| CN109120385B (zh) | 一种基于数据传输系统的数据传输方法、装置及系统 | |
| Bhattacharyya et al. | Constrained application protocol (CoAP) option for no server response | |
| JP2020091512A (ja) | 社内ネットワーク上の社内サーバに対する操作を伴う業務プロセスを自動化するための装置、方法及びそのためのプログラム | |
| JP5383923B1 (ja) | 情報処理装置、情報処理システム、情報処理方法およびプログラム | |
| WO2015100932A1 (zh) | 一种网络数据的传输方法、装置及系统 | |
| JP4536029B2 (ja) | 通信プロトコルを用いた相互接続方法および装置 | |
| JP6131710B2 (ja) | 通信システム、負荷分散装置、および、負荷分散プログラム | |
| JP2007299019A (ja) | データ通信システム、サーバ装置及びそれに用いるデータ通信方法並びにそのプログラム | |
| EP3408989B1 (en) | Detecting malware on spdy connections | |
| CN109155792B (zh) | 更新以内容为中心的网络中的传输栈 | |
| JP2011044823A (ja) | 通信装置、通信システム、通信方法及び通信プログラム | |
| JP5726720B2 (ja) | Ｗｅｂ情報取得方法および先読み代理サーバ | |
| JP6667341B2 (ja) | ネットワークシステム |