JP2020024567A - Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム - Google Patents
Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム Download PDFInfo
- Publication number
- JP2020024567A JP2020024567A JP2018148615A JP2018148615A JP2020024567A JP 2020024567 A JP2020024567 A JP 2020024567A JP 2018148615 A JP2018148615 A JP 2018148615A JP 2018148615 A JP2018148615 A JP 2018148615A JP 2020024567 A JP2020024567 A JP 2020024567A
- Authority
- JP
- Japan
- Prior art keywords
- api
- oas
- unit
- setting
- parameters
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/73—Program documentation
Abstract
【課題】ＡＰＩリクエスト−レスポンスをもとに低コストでＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供する。【解決手段】ＡＰＩ仕様書生成装置１００は、ＯＡＳ仕様書を作成する際の雛形ファイル１２１をあらかじめ設定するＯＡＳ雛形設定部１１１と、ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２を設定する挿入値ファイル設定部１１２と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ部１０２と、キャプチャしたＡＰＩリクエスト−レスポンスデータと、挿入値ファイルの参照結果とを雛形ファイルに反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書を作成するＯＡＳ作成部１１０とを備える。【選択図】図２
Description
本発明は、ＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムに関する。
各事業者がサービスを管理するためのＡＰＩ（Application Program Interface）をウェブ上にて提供しており、ユーザはＡＰＩを呼び出すソフトウェアを通じてサービスを構築・運用している。ＡＰＩの仕様（ＡＰＩの名称、ＵＲＬ（Uniform Resource Locator）、パラメータ等）は、各事業者が規定しており、ユーザは当該規定に従ってＡＰＩを使用する。
既存機能やＡＰＩ仕様をＯＡＳ（Open API spec）仕様に変換する技術として、非特許文献１，２に記載された技術がある。また、ＯＡＳを活用した関連技術には、非特許文献３〜５に記載された技術がある。
非特許文献１には、データベース（ＤＢ）からWeb APIをドキュメント(Open API標準)と共に自動作成するツールが記載されている。
非特許文献２には、ＡＰＩリクエスト−レスポンスから簡易的なＯＡＳ仕様書を自動作成するツールが記載されている。
非特許文献３には、存在従属グラフからSwagger仕様書の生成クラス図のようなドメインモデルからSwagger Specを作成する技術が記載されている。
非特許文献４には、ＡＰＩ設計書に記載されているＡＰＩ特有のパラメータ（ＡＰＩ概要、メソッド等）を解析し、Semantic的エラーを検出する技術が記載されている。
非特許文献５には、開発済のＡＰＩを、ＴＭＦ（TM Forum members）提供のＣＴＫ（Conformance Test Kits）に従いNewmanというツールを用いてＡＰＩリクエストを送ると、Syntax的にＴＭＦ準拠になっているかチェックするツールが記載されている。このツールは、テスト結果をhtmlやjsonファイルとして生成する。
ＯＡＳベースで設計／（「／」は、「および／または」、を表記する。以下同様。）開発されていない既存ＡＰＩ（以降、「既存ＡＰＩ」という)仕様を標準仕様書であるＯＡＳ形式にする場合について説明する。
図１２は、ＯＡＳ仕様書作成を説明する図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２（ａ）中、二重線で示される表記は、ＡＰＩを示す（以下、各図において同様）。図１３は、図１２の簡易ＯＡＳフォーマット作成ツールで用いるＡＰＩリクエストおよびＡＰＩレスポンスの一例を示す図である。
図１２（ａ）に示すように、ＡＰＬ（Application）サービス（以下、既存ＡＰＬという）１１と既存機能１２（既存機能Ａ１２という）との間には、インターフェースであるＲＥＳＴ（REpresentational State Transfer） ＡＰＩ１０が設けられている。なお、ＲＥＳＴ ＡＰＩ１０は、ＨＴＴＰ以外のプロトコルに対応した機能はない。
図１２は、ＯＡＳ仕様書作成を説明する図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２（ａ）中、二重線で示される表記は、ＡＰＩを示す（以下、各図において同様）。図１３は、図１２の簡易ＯＡＳフォーマット作成ツールで用いるＡＰＩリクエストおよびＡＰＩレスポンスの一例を示す図である。
図１２（ａ）に示すように、ＡＰＬ（Application）サービス（以下、既存ＡＰＬという）１１と既存機能１２（既存機能Ａ１２という）との間には、インターフェースであるＲＥＳＴ（REpresentational State Transfer） ＡＰＩ１０が設けられている。なお、ＲＥＳＴ ＡＰＩ１０は、ＨＴＴＰ以外のプロトコルに対応した機能はない。
既存ＡＰＩからＯＡＳ仕様書を作成する場合、簡易ＯＡＳフォーマット作成ツール（図１２（ａ）の符号ａ参照）を用いて、既存ＡＰＩのリクエスト−レスポンスを解析する。例えば、図１２（ｂ）に示すＡＰＩリクエスト−レスポンス１２６（ＨＴＴＰ）を解析する。ＡＰＩリクエスト−レスポンス１２６は、図１３に示すＡＰＩリクエスト１２４およびＡＰＩレスポンス１２５からなる。
図１２（ｂ）の符号ｂに示すように、簡易ＯＡＳフォーマット作成ツールを用いて、機能ＡについてＯＡＳ形式のフォーマット（機能Ａ ＯＡＳフォーマット２０）を生成する。
図１２（ｂ）の符号ｃに示すように、開発者が、生成された機能Ａ ＯＡＳフォーマット２０に対してパラメータ等の修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成する。
機能Ａ ＯＡＳフォーマット２０に、微修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成している。
図１２（ｂ）の符号ｃに示すように、開発者が、生成された機能Ａ ＯＡＳフォーマット２０に対してパラメータ等の修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成する。
機能Ａ ＯＡＳフォーマット２０に、微修正を加えて、機能Ａ ＯＡＳ仕様書２１を作成している。
API Server: データベースからREST API を超高速で自動生成,［online］,［平成３０年７月１５日検索］,インターネット 〈URL: https://www.cdata.com/jp/apiserver/〉
Swagger inspector,［online］,［平成３０年７月１５日検索］,インターネット 〈URL: https://inspector.swagger.io/builder〉
井田明男，他２名，「存在従属グラフからSWAGGER仕様書の生成」，信学技報, IEICE Technical Report KBSE2016-29(2016-11)
小俣真吾，「API記述ルールに準拠したAPI設計支援方法に関する一検討」，第14 回NWS 研究会，Oct., 2017
CTK(Compatibility Test Kit),［online］,［平成３０年７月１５日検索］,インターネット 〈URL: github.com/tmforum/CustomerManagementCTK〉
上述したように、既存のＲＥＳＴ ＡＰＩのＡＰＩリクエスト−レスポンス１２６の解析のみで簡易なＯＡＳ仕様書２１の作成は可能である。
しかしながら、（１）単純なＡＰＩリクエスト−レスポンス１２６のみの解析では、ＯＡＳの仕様を決められないパラメータ（データ型、データ範囲、値の最大値／最小値等）が存在する。例えば、データ型（“string”，“number”，“integer”，“boolean”，“array”等）の決定や値の範囲（maximum minimum）を一意に特定してＯＡＳに反映させるのは難しく、加筆修正する必要がある。そのため、ＯＡＳ仕様書を自動生成させても、ＯＡＳ仕様書を修正する稼働が発生する。また、ＨＴＴＰ（Hypertext Transfer Protocol）以外のプロトコルに対応したＯＡＳ仕様書の自動生成技術は存在しない。
しかしながら、（１）単純なＡＰＩリクエスト−レスポンス１２６のみの解析では、ＯＡＳの仕様を決められないパラメータ（データ型、データ範囲、値の最大値／最小値等）が存在する。例えば、データ型（“string”，“number”，“integer”，“boolean”，“array”等）の決定や値の範囲（maximum minimum）を一意に特定してＯＡＳに反映させるのは難しく、加筆修正する必要がある。そのため、ＯＡＳ仕様書を自動生成させても、ＯＡＳ仕様書を修正する稼働が発生する。また、ＨＴＴＰ（Hypertext Transfer Protocol）以外のプロトコルに対応したＯＡＳ仕様書の自動生成技術は存在しない。
（２）ＡＰＩリクエスト−レスポンス１２６のデータから、どのようなロジックでＯＡＳパラメータに反映するかのルールを設定する機能は存在しない。このため、各社独自パラメータやＨＴＴＰ以外のプロトコルに対応できていない。
以上の理由から、非特許文献１〜５に記載された技術ついても下記の課題がある。
非特許文献１に記載の技術は、特定のＤＢから機械的にパラメータを設定可能な領域に限定した簡易なＯＡＳを作成することはできるものの、一意に特定不可なパラメータまでは設定できない。また、パラメータ設定のロジックを組むことも不可である。
非特許文献１に記載の技術は、特定のＤＢから機械的にパラメータを設定可能な領域に限定した簡易なＯＡＳを作成することはできるものの、一意に特定不可なパラメータまでは設定できない。また、パラメータ設定のロジックを組むことも不可である。
非特許文献２に記載の技術は、パラメータを機械的に、設定可能な領域に限定した簡易なＯＡＳを作成することはできるものの、一意に特定不可なパラメータ（データ型、値の範囲等）までは設定できない。また、パラメータ設定のロジックを組むことも不可である。さらに、ＨＴＴＰのみに対応であり、他のプロトコルに対応していない。
非特許文献３に記載の技術は、ＡＰＩリクエスト−レスポンスの結果をもとに、Swagger Specを作成する技術については触れられていない。
非特許文献４に記載の技術は、ＯＡＳ仕様書の作成について手書きを前提としており、既存ＡＰＩのリクエストレスポンスを解析してＯＡＳ仕様書を自動生成する機能には触れられていない。また、非特許文献４に記載の技術は、カスタマイズ領域が特定の記述ルールに準拠しているか否かをチェックするチェックルールに限定されている。非特許文献４に記載の技術は、ＡＰＩリクエスト−レスポンスパラメータの値をもとにＯＡＳ仕様書を作成する機能については触れられていない。
非特許文献５に記載の技術は、特定の記述ルールのうちSyntaxエラーを検出するツールであり、非特許文献５に記載の技術は、特定のルールへの準拠性を確認するのみである。このため、非特許文献５に記載の技術では、準拠性を確認するルールのカスタマイズは難しい。また、開発済ＡＰＩのリクエスト−レスポンスの結果からSwagger Specを自動生成する技術は具備していない。
上記非特許文献１〜５のいずれの技術についても、ＡＰＩリクエスト−レスポンスからデータ型や値の範囲まで反映するＯＡＳ仕様書の自動生成機能は提案されていない。様々なプロトコルに対応可能なカスタマイズ性を担保した機能も述べられていない。
このような背景に鑑みて本発明がなされたのであり、本発明は、ＡＰＩリクエスト−レスポンスをもとに低コストでＲＥＳＴ ＡＰＩの標準仕様書であるＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置であって、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定部と、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定部と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ部と、キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成部と、を備えることを特徴とするＡＰＩ仕様書生成装置とした。
また、請求項４に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置が、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するステップと、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定するステップと、ＡＰＩリクエストとそのレスポンスをキャプチャするステップと、キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するステップと、を実行することを特徴とするＡＰＩ仕様書生成方法とした。
また、請求項５に記載の発明は、既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置としてのコンピュータを、前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定手段、前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定手段、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ手段、キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成手段、として機能させるためのプログラムとした。
このようにすることで、ＡＰＩリクエスト−レスポンスをもとに低コストでデータ型や値の範囲まで反映するＯＡＳ仕様書を作成できる。また、各種プロトコルの値から、ＯＡＳにパラメータをどのように設定するかを記述するパラメータ設定ロジックも、システム運用者にてカスタマイズ可能である。さらに、独自パラメータやＨＴＴＰ以外のプロトコルもＯＡＳ仕様書の対象にすることができる。
また、請求項２に記載の発明は、一意にＯＡＳ仕様書へパラメータを登録するパラメータ設定辞書を格納するパラメータ設定辞書格納部をさらに備え、前記ＯＡＳ作成部は、キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記パラメータ設定辞書を参照して、前記暫定パラメータを、当該暫定パラメータよりも精度の高いパラメータに設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成することを特徴とする請求項１に記載のＡＰＩ仕様書生成装置とした。
このようにすることで、ＡＰＩリクエスト−レスポンスとＡＰＩパラメータ設定辞書を参照して、一意に特定不可であるパラメータも高精度で設計可能となる。このため、ＯＡＳ仕様書の作成および修正稼働を削減することができる。
また、請求項３に記載の発明は、アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力するＡＰＩ記述ルール入力部と、前記ＡＰＩ記述ルールを解析してチェックポリシーを作成するＡＰＩ記述ルール解析部と、前記チェックポリシーに基づいて前記ＡＰＩ記述ルールに準拠していることをチェックする準拠性チェック処理部と、をさらに備え、前記ＯＡＳ作成部は、作成した前記ＯＡＳ仕様書を前記準拠性チェック処理部に送り、前記準拠性チェック処理部は、前記ＯＡＳ作成部から送られた前記ＯＡＳ仕様書をもとに、前記ＡＰＩ記述ルールへの準拠性をチェックすることを特徴とする請求項１に記載のＡＰＩ仕様書生成装置とした。
このようにすることで、生成されたＡＰＩ仕様書について、特定のＡＰＩ記述ルールへの準拠性も確認することができる。
本発明によれば、ＡＰＩリクエスト−レスポンスをもとに低コストでＯＡＳ仕様書を作成できるＡＰＩ仕様書生成装置、ＡＰＩ仕様書生成方法、およびプログラムを提供することができる。
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるＡＰＩ仕様書生成装置等について説明する。
（原理説明）
図１は、本発明の実施形態に係るＡＰＩ仕様書生成装置の概要を示す図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２および図１３と同一構成部分には同一符号を付している。
ＡＰＩ仕様書生成装置１００は、既存ＡＰＩの仕様を自動で標準仕様の仕様書に変換し生成する。
図１（ａ）に示すように、ＡＰＩ仕様書生成装置１００は、ＲＥＳＴ ＡＰＩ１０と既存機能１２間で送受信されるＡＰＩリクエスト−レスポンスをキャプチャ可能に設置される（詳細後記）。
図１（ｂ）の符号ｄに示すように、キャプチャブロック＃１でキャプチャされたＡＰＩリクエスト−レスポンス１２６は、ＯＡＳ生成処理ブロック＃２に出力される。
（原理説明）
図１は、本発明の実施形態に係るＡＰＩ仕様書生成装置の概要を示す図であり、（ａ）はその全体構成図、（ｂ）はその動作説明図である。図１２および図１３と同一構成部分には同一符号を付している。
ＡＰＩ仕様書生成装置１００は、既存ＡＰＩの仕様を自動で標準仕様の仕様書に変換し生成する。
図１（ａ）に示すように、ＡＰＩ仕様書生成装置１００は、ＲＥＳＴ ＡＰＩ１０と既存機能１２間で送受信されるＡＰＩリクエスト−レスポンスをキャプチャ可能に設置される（詳細後記）。
図１（ｂ）の符号ｄに示すように、キャプチャブロック＃１でキャプチャされたＡＰＩリクエスト−レスポンス１２６は、ＯＡＳ生成処理ブロック＃２に出力される。
ＯＡＳ生成処理ブロック＃２は、ＯＡＳ雛形設定部１１１（後記）、挿入値ファイル設定部１１２（後記）、パラメータ設定辞書１２３（後記）を有する。
ＯＡＳ生成処理ブロック＃２では、パラメータ設定ロジックを含むＡＰＩガイドラインファイルに従い、あらかじめ用意してある雛形ファイル１２１に挿入値ファイル１２２の参照結果とパラメータを反映する（図１（ｂ）の符号ｅ参照）。
また、一意に特定不可であるパラメータについては、例えばＡＰＩガイドラインファイルのパラメータ設定ロジックに従い、パラメータ設定辞書１２３を参照の上、パラメータを設定する（図１（ｂ）の符号ｆ参照）。
ＯＡＳ生成処理ブロック＃２では、パラメータ設定ロジックを含むＡＰＩガイドラインファイルに従い、あらかじめ用意してある雛形ファイル１２１に挿入値ファイル１２２の参照結果とパラメータを反映する（図１（ｂ）の符号ｅ参照）。
また、一意に特定不可であるパラメータについては、例えばＡＰＩガイドラインファイルのパラメータ設定ロジックに従い、パラメータ設定辞書１２３を参照の上、パラメータを設定する（図１（ｂ）の符号ｆ参照）。
ＡＰＩ仕様書生成装置１００は、特定のＡＰＩ記述ルールへの準拠性も確認する。すなわち、図１（ｂ）の符号ｇに示すように、ＯＡＳ生成処理ブロック＃２で生成したＯＡＳをＯＡＳ出力ブロック＃３に出力し、特定のＡＰＩ記述ルールへの準拠性も確認する（後記）。
（実施形態）
図２は、本発明の実施形態に係るＡＰＩ仕様書生成装置を示す構成図である。
図２に示すように、既存ＡＰＬ１１は、ＲＥＳＴ ＡＰＩ１０およびＬ２（layer2）スイッチ１５を介してＡＰＩ提供装置（既存機能）２０に接続される。既存ＡＰＬ１１は、既存ＡＰＩ開発者１が使用するものとする。Ｌ２スイッチ１５は、パケットのＭＡＣ（Media Access Control）アドレスにより中継先を判断して中継動作を行う。
図２は、本発明の実施形態に係るＡＰＩ仕様書生成装置を示す構成図である。
図２に示すように、既存ＡＰＬ１１は、ＲＥＳＴ ＡＰＩ１０およびＬ２（layer2）スイッチ１５を介してＡＰＩ提供装置（既存機能）２０に接続される。既存ＡＰＬ１１は、既存ＡＰＩ開発者１が使用するものとする。Ｌ２スイッチ１５は、パケットのＭＡＣ（Media Access Control）アドレスにより中継先を判断して中継動作を行う。
ＡＰＩ仕様書生成装置１００は、ＲＥＳＴ ＡＰＩ１０とＡＰＩ提供装置２０間に設置される。ＡＰＩ仕様書生成装置１００は、既存ＡＰＩの仕様を自動で標準仕様の仕様書に変換し生成する。
ＡＰＩ仕様書生成装置１００は、既存ＡＰＩ開発者２からの入力を受付けるＡＰＩリクエスト−レスポンスＩＦ部１０１と、ＡＰＩリクエスト−レスポンスキャプチャ部１０２と、ＯＡＳ作成部１１０と、ＯＡＳ雛形設定部１１１と、挿入値ファイル設定部１１２と、パラメータ設定辞書格納部１１３と、を備える。上記ＯＡＳ雛形設定部１１１、挿入値ファイル設定部１１２およびパラメータ設定辞書格納部１１３は、ＡＰＩ記述ルール作成者／システム運用者３からの入力を受付ける。
また、ＡＰＩ仕様書生成装置１００は、ＡＰＩ記述ルール設定方式入力部１０３と、ＡＰＩ記述ルール作成者／システム運用者３からの入力を受付けるＡＰＩ記述ルール入力部１０４と、ＡＰＩ記述ルール作成者／システム運用者４からの入力を受付けるＡＰＩ記述ルール解析部１０５と、チェックポリシー設定部１０６と、既存ＡＰＩ開発者５からの入力を受付けるＡＰＩ設計エディタ部１０７と、準拠性チェック処理部１０８と、を備える。
なお、既存ＡＰＩ開発者１、既存ＡＰＩ開発者２、および既存ＡＰＩ開発者５は、同一の開発者であってもよい。ＡＰＩ記述ルール作成者／システム運用者３およびＡＰＩ記述ルール作成者／当該システム運用者４は、同一の運用者であってもよい。
なお、既存ＡＰＩ開発者１、既存ＡＰＩ開発者２、および既存ＡＰＩ開発者５は、同一の開発者であってもよい。ＡＰＩ記述ルール作成者／システム運用者３およびＡＰＩ記述ルール作成者／当該システム運用者４は、同一の運用者であってもよい。
ＡＰＩリクエスト−レスポンスＩＦ部１０１は、既存ＡＰＩ開発者２からの入力を変換してＡＰＩ提供装置２０に送信するととともに、ＡＰＩリクエスト−レスポンスキャプチャ部１０２に該当ＡＰＩリクエスト−レスポンスのデータ取込みを設定する。なお、ＡＰＩ提供装置２０は、ＡＰＩリクエスト−レスポンスＩＦ部１０１からの送信に対する応答を返す。
なお、上記ＡＰＩリクエスト−レスポンスのデータは、具体的にはＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値（詳細後記）である。
なお、上記ＡＰＩリクエスト−レスポンスのデータは、具体的にはＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値（詳細後記）である。
ＡＰＩリクエスト−レスポンスキャプチャ部１０２は、ＡＰＩリクエストとそのレスポンスであるＡＰＩリクエスト−レスポンス１２６（図１３参照）をキャプチャする。図２では、ＡＰＩリクエスト−レスポンスキャプチャ部１０２は、Ｌ２スイッチ１５により中継されたＡＰＩリクエスト−レスポンス１２６をキャプチャし、キャプチャしたＡＰＩリクエスト−レスポンス１２６をＯＡＳ作成部１１０に出力する。
ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンス１２６（図１３参照）データと、挿入値ファイル１２２（図４参照）の参照結果とを雛形ファイル１２１（図３参照）に反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書１２７（図６参照）を作成する。
なお、ＡＰＩリクエスト−レスポンス１２６のパラメータに応じて変更する部分は、置換箇所を示す変換タグを記載する。
また、ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト−レスポンスデータと、パラメータ設定辞書１２３（図５参照）を参照して、暫定パラメータをより精度の高いパラメータに設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成する。
また、ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト−レスポンスデータと、パラメータ設定辞書１２３（図５参照）を参照して、暫定パラメータをより精度の高いパラメータに設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成する。
ＯＡＳ作成部１１０は、ＡＰＩリクエスト−レスポンス１２６（図１３参照）のみでは一意に決められず、パラメータ設定辞書１２３の参照が必要とされる領域は、該当するＯＡＳタグ部分に辞書への参照命令を記載する。
なお、挿入値ファイル１２２に記載するパラメータ設定ロジックの書き方によっては、ＨＴＴＰ以外のプロトコルもＯＡＳ仕様書１２７に自動反映することも可能である（後記図８参照）。
なお、挿入値ファイル１２２に記載するパラメータ設定ロジックの書き方によっては、ＨＴＴＰ以外のプロトコルもＯＡＳ仕様書１２７に自動反映することも可能である（後記図８参照）。
ＯＡＳ雛形設定部１１１は、ＯＡＳ仕様書１２７（図６参照）を作成する際のＯＡＳ雛形（雛形ファイル１２１）（図３参照）をあらかじめ設定する。雛形ファイル１２１は、置換箇所を変換タグとして記載する。
挿入値ファイル設定部１１２は、ＯＡＳ仕様書１２７（図６参照）で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２（図４参照）を設定する。挿入値ファイル１２２は、雛形ファイル１２１に反映するパラメータ設定ロジックを有する。挿入値ファイル設定部１１２は、雛形ファイル１２１（図３参照）記載の変換タグに対応した挿入値ファイル１２２を設定する。
パラメータ設定辞書格納部１１３は、一意にＯＡＳ仕様書１２７（図６参照）へ反映が難しいパラメータを登録するパラメータ設定辞書１２３（図５参照）を格納する。
ＡＰＩ記述ルール設定方式入力部１０３は、ＡＰＩ記述ルールの記述様式を入力する。例えば、ＡＰＩ記述ルール作成者／システム運用者４がＡＰＩ記述ルールの記述様式をＡＰＩ記述ルール設定方式入力部１０３にあらかじめ入力する。
ＡＰＩ記述ルール入力部１０４は、アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力する。
ＡＰＩ記述ルール入力部１０４は、ＡＰＩ記述ルール作成者／システム運用者３が、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力するインポート（import）部である。上記ＡＰＩ記述ルールは、ＡＰＩ仕様書生成装置１００が指定する記述様式に従って記載されたSyntax的なＡＰＩ記述ルール、および、Semantic的なＡＰＩ記述ルールである。具体的には、上記Syntax的なエラーは、構文／文法的なエラーである。上記Semantic的なエラーは、ＡＰＩ仕様の設計に関する領域において、使用しているメソッドがＣＲＵＤ（Create，Read，Update，Delete）の考え方に従っているか等意味の違いや矛盾によって生じるエラーである。
ＡＰＩ記述ルール入力部１０４は、ＡＰＩ記述ルール作成者／システム運用者３が、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力するインポート（import）部である。上記ＡＰＩ記述ルールは、ＡＰＩ仕様書生成装置１００が指定する記述様式に従って記載されたSyntax的なＡＰＩ記述ルール、および、Semantic的なＡＰＩ記述ルールである。具体的には、上記Syntax的なエラーは、構文／文法的なエラーである。上記Semantic的なエラーは、ＡＰＩ仕様の設計に関する領域において、使用しているメソッドがＣＲＵＤ（Create，Read，Update，Delete）の考え方に従っているか等意味の違いや矛盾によって生じるエラーである。
また、ＡＰＩ記述ルール入力部１０４は、ＡＰＩ記述ルール作成者／システム運用者３が、チェックポリシーを記載したソースコード等を入力する。
ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルールを解析してチェックポリシーを作成する。詳細には、ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルール設定方式入力部１０３により事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを作成する。作成したチェックポリシーは、チェックポリシー設定部１０６に送られる。
チェックポリシー設定部１０６は、ＡＰＩ記述ルール作成者／システム運用者４が、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１０６は、チェックポリシーを準拠性チェック処理部１０８に反映する。
ＡＰＩ設計エディタ部１０７は、既存ＡＰＩ開発者５が、ＡＰＩ設計書を入力する。
準拠性チェック処理部１０８は、チェックポリシーに基づいてＡＰＩ記述ルールに準拠していることをチェックする。準拠性チェック処理部１０８は、ＯＡＳ作成部１１０から送られたＯＡＳ仕様書１２７をもとに、ＡＰＩ記述ルールへの準拠性をチェックする。
具体的には、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書の入力を受け付け、入力されたＡＰＩ設計書をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する。
ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書を入力してもよいし、ＡＰＩ仕様書生成装置１００の提供するＡＰＩを用いてＡＰＩ設計書を送付してもよい。ＡＰＩ記述ルール作成者／システム運用者３がＡＰＩ設計エディタ部１０７を用いたときは、ＡＰＩ設計書の非準拠箇所をＡＰＩ設計エディタ部１０７に出力し、既存ＡＰＩ開発者５に通知する。
具体的には、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書の入力を受け付け、入力されたＡＰＩ設計書をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する。
ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書を入力してもよいし、ＡＰＩ仕様書生成装置１００の提供するＡＰＩを用いてＡＰＩ設計書を送付してもよい。ＡＰＩ記述ルール作成者／システム運用者３がＡＰＩ設計エディタ部１０７を用いたときは、ＡＰＩ設計書の非準拠箇所をＡＰＩ設計エディタ部１０７に出力し、既存ＡＰＩ開発者５に通知する。
なお、図２のＡＰＩリクエスト−レスポンスＩＦ部１０１およびＡＰＩリクエスト−レスポンスキャプチャ部１０２は、図１のキャプチャブロック＃１に対応する。図２のＯＡＳ作成部１１０、ＯＡＳ雛形設定部１１１、挿入値ファイル設定部１１２、およびパラメータ設定辞書格納部１１３は、図１のＯＡＳ生成処理ブロック＃２に対応する。図２のＡＰＩ記述ルール設定方式入力部１０３、ＡＰＩ記述ルール入力部１０４、ＡＰＩ記述ルール解析部１０５、チェックポリシー設定部１０６、ＡＰＩ設計エディタ部１０７、および準拠性チェック処理部１０８、図１のＯＡＳ出力ブロック＃３に対応する。
<雛形ファイル１２１>
図３は、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１の一例を示す図である。
雛形ファイル１２１は、ＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書１２７（図６参照）を作成するための雛形である。雛形ファイル１２１は、置換箇所を変換タグとして記載する。
図３は、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１の一例を示す図である。
雛形ファイル１２１は、ＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書１２７（図６参照）を作成するための雛形である。雛形ファイル１２１は、置換箇所を変換タグとして記載する。
雛形ファイル１２１には、ＡＰＩリクエスト−レスポンス１２６のパラメータに応じて変更する部分に、置換箇所を示す変換タグが記載される。図３に示す雛形ファイル１２１は、「！！」に示す置換箇所（図３の太文字参照）が変換タグとして記載される。
<挿入値ファイル１２２>
図４は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２の一例を示す図である。
挿入値ファイル１２２は、雛形ファイル１２１（図３参照）に反映するパラメータ設定ロジックを有する。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書１２３を参照するなどして決定する。
図４は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２の一例を示す図である。
挿入値ファイル１２２は、雛形ファイル１２１（図３参照）に反映するパラメータ設定ロジックを有する。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書１２３を参照するなどして決定する。
図４の符号ｗに示すように、
・host.yaml
host: [Host: ]は、リクエスト−レスポンスのHost:ヘッダの内容を、そのまま反映する。
・host.yaml
host: [Host: ]は、リクエスト−レスポンスのHost:ヘッダの内容を、そのまま反映する。
図４の符号ｘに示すように、
・basePath.yaml
basePath: [Request URI: - Host: ]は、リクエストパラメータの各パラメータを参照してどのようにＯＡＳへ反映するかを設定する。本実施形態では、Request URLヘッダの値からHost:ヘッダの値を差し引いた値をbasePath: として設定するロジックを記載する。
・basePath.yaml
basePath: [Request URI: - Host: ]は、リクエストパラメータの各パラメータを参照してどのようにＯＡＳへ反映するかを設定する。本実施形態では、Request URLヘッダの値からHost:ヘッダの値を差し引いた値をbasePath: として設定するロジックを記載する。
図４の符号ｙに示すように、
・type_1.yaml
[Member Key: SELECT ParameterType FROM ParameterＤＢ WHERE [Member Key] = ParameterＤＢ.Word ]は、データ型等、ＡＰＩリクエスト−レスポンスの単純解析では、一意に特定不可なパラメータについて、パラメータ設定辞書を参照して設定する。
・type_1.yaml
[Member Key: SELECT ParameterType FROM ParameterＤＢ WHERE [Member Key] = ParameterＤＢ.Word ]は、データ型等、ＡＰＩリクエスト−レスポンスの単純解析では、一意に特定不可なパラメータについて、パラメータ設定辞書を参照して設定する。
<パラメータ設定辞書１２３>
図５は、ＯＡＳ作成部１１０の動作を示す図である。ＯＡＳ作成部１１０の動作については、後記し、パラメータ設定辞書１２３の構成例について述べる。
パラメータ設定辞書１２３は、一意にＯＡＳ仕様書１２７（図６参照）へ反映が難しいパラメータを登録する。
図５に示すように、パラメータ設定辞書１２３は、Word(項目)に対応するType(型)、format(フォーマット)、maximum(最大値)、およびminimum(最小値)を有する。Wordは、例えば、Birthday、Telephone、Creditである。Typeは、例えば、integer(整数)である。formatは、int32(整数32bit)、int64(整数64bit)である。
図５は、ＯＡＳ作成部１１０の動作を示す図である。ＯＡＳ作成部１１０の動作については、後記し、パラメータ設定辞書１２３の構成例について述べる。
パラメータ設定辞書１２３は、一意にＯＡＳ仕様書１２７（図６参照）へ反映が難しいパラメータを登録する。
図５に示すように、パラメータ設定辞書１２３は、Word(項目)に対応するType(型)、format(フォーマット)、maximum(最大値)、およびminimum(最小値)を有する。Wordは、例えば、Birthday、Telephone、Creditである。Typeは、例えば、integer(整数)である。formatは、int32(整数32bit)、int64(整数64bit)である。
図５に示すパラメータ設定辞書１２３で、例えば、Word「Birthday」が検索されると、Type 「integer」、format「int32」、maximum「99999999」、およびminimum「00」が参照される。Word「Birthday」の場合、maximumは、yyyymmdd(西暦4桁,月2桁,日2桁)が設定され、minimumは、dd(日2桁)が設定されている。このため、minimumに「00」(2桁)より大きいパラメータは設定できない。
同様に、Word「Telephone」が検索されると、Type 「integer」、format「int32」、maximum「−(設定なし)」、およびminimum「0000000000」(8桁)が参照される。
同様に、Word「Telephone」が検索されると、Type 「integer」、format「int32」、maximum「−(設定なし)」、およびminimum「0000000000」(8桁)が参照される。
ＯＡＳ作成部１１０は、パラメータ設定辞書１２３を参照することで、リクエスト−レスポンスの解析のみでは機械的に設定できないパラメータついても、高い精度で適切なパラメータを設定することが可能となる（後記）。
以下、上述のように構成されたＡＰＩ仕様書生成装置１００のＡＰＩ仕様書生成方法について説明する。
［全体動作］
ＳＴＥＰ１
図２の符号ｈに示すように、既存ＡＰＬ１１からＡＰＩ提供装置２０に対してＡＰＩリクエストを送信する。
［全体動作］
ＳＴＥＰ１
図２の符号ｈに示すように、既存ＡＰＬ１１からＡＰＩ提供装置２０に対してＡＰＩリクエストを送信する。
ＳＴＥＰ２
ＡＰＬリクエストがない場合、図２の符号ｉに示すように、既存ＡＰＩ開発者２は、既存ＡＰＩ１１にＡＰＩリクエストを送信するために必要な情報（ＵＲＬ，リクエストパラメータ等）を入力する。既存ＡＰＩ開発者２は、ＡＰＩリクエストに対するレスポンス結果も確認する。
ＡＰＬリクエストがない場合、図２の符号ｉに示すように、既存ＡＰＩ開発者２は、既存ＡＰＩ１１にＡＰＩリクエストを送信するために必要な情報（ＵＲＬ，リクエストパラメータ等）を入力する。既存ＡＰＩ開発者２は、ＡＰＩリクエストに対するレスポンス結果も確認する。
ＳＴＥＰ３
図２の符号ｊに示すように、ＡＰＩリクエスト−レスポンスキャプチャ部１０２は、Ｌ２スイッチ１５により中継されたＡＰＩリクエスト−レスポンス１２６（図１３参照）をキャプチャする。
図２の符号ｊに示すように、ＡＰＩリクエスト−レスポンスキャプチャ部１０２は、Ｌ２スイッチ１５により中継されたＡＰＩリクエスト−レスポンス１２６（図１３参照）をキャプチャする。
ＳＴＥＰ４
図２の破線矢印および符号ｋに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＯＡＳ雛形設定部１１１の雛形ファイル１２１、挿入値ファイル設定部１１２の挿入値ファイル１２２、パラメータ設定辞書格納部１１３のパラメータ設定辞書１２３について、手動により雛形ファイル１２１、挿入値ファイル１２２、パラメータ設定辞書１２３を充実化またはカスタマイズさせる。
図２の破線矢印および符号ｋに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＯＡＳ雛形設定部１１１の雛形ファイル１２１、挿入値ファイル設定部１１２の挿入値ファイル１２２、パラメータ設定辞書格納部１１３のパラメータ設定辞書１２３について、手動により雛形ファイル１２１、挿入値ファイル１２２、パラメータ設定辞書１２３を充実化またはカスタマイズさせる。
ＳＴＥＰ５
図２の符号ｌに示すように、ＯＡＳ作成部１１０は、ＯＡＳ雛形設定部１１１に設定された雛形ファイル１２１（図３参照）に、ＡＰＩリクエスト−レスポンスキャプチャ部１０２でキャプチャされたＡＰＩリクエスト−レスポンス１２６のキャプチャデータと挿入値ファイル設定部１１２の参照結果とを反映させる。
図２の符号ｌに示すように、ＯＡＳ作成部１１０は、ＯＡＳ雛形設定部１１１に設定された雛形ファイル１２１（図３参照）に、ＡＰＩリクエスト−レスポンスキャプチャ部１０２でキャプチャされたＡＰＩリクエスト−レスポンス１２６のキャプチャデータと挿入値ファイル設定部１１２の参照結果とを反映させる。
ＳＴＥＰ６
図２の符号ｍに示すように、ＯＡＳ作成部１１０は、一意にＯＡＳへ反映が難しいパラメータは、パラメータ設定辞書格納部１１３が格納するパラメータ設定辞書１２３（図５参照）を参照して、暫定的にパラメータを設定する。
図２の符号ｍに示すように、ＯＡＳ作成部１１０は、一意にＯＡＳへ反映が難しいパラメータは、パラメータ設定辞書格納部１１３が格納するパラメータ設定辞書１２３（図５参照）を参照して、暫定的にパラメータを設定する。
ＳＴＥＰ７
図２の符号ｎに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール入力部１０４に、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力する。ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール設定方式入力部１０３（後記）で設定された記述様式に従ってＡＰＩ記述ルールを記載する。
図２の符号ｎに示すように、ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール入力部１０４に、アノテーションや正規表現等の一般的なプログラミング言語、または、ＡＰＩ仕様書生成装置１００が指定するＡＰＩ特有の記述様式に従って記載されたＡＰＩ記述ルールを入力する。ＡＰＩ記述ルール作成者／システム運用者３は、ＡＰＩ記述ルール設定方式入力部１０３（後記）で設定された記述様式に従ってＡＰＩ記述ルールを記載する。
上記ＡＰＩ記述ルールは、ＡＰＩ仕様書生成装置１００が指定する記述様式に従って記載されたSyntax的なＡＰＩ記述ルール、および、Semantic的なＡＰＩ記述ルールである。具体的には、ＡＰＩ記述ルールは、ＡＰＩのリソース名、パラメータ名に使用してはいけない文字や文字列を規定したルール、およびＡＰＩで使用するメソッドの使用用途を規定したルールなどである。メソッドの使用用途は、ＲＥＳＴ ＡＰＩ１０のメソッドが限定的な特徴を活かしてルールを規定できる。
また、ＡＰＩ記述ルール作成者／システム運用者３は、チェックポリシーを記載したソースコード等を入力する。
また、ＡＰＩ記述ルール作成者／システム運用者３は、チェックポリシーを記載したソースコード等を入力する。
ＳＴＥＰ８
ＡＰＩ記述ルール設定方式入力部１０３は、ＡＰＩ記述ルールの記述様式を入力する。このＡＰＩ記述ルールの記述様式は、例えばＡＰＩ記述ルール作成者／システム運用者４があらかじめ入力する。
ＡＰＩ記述ルール設定方式入力部１０３は、ＡＰＩ記述ルールの記述様式を入力する。このＡＰＩ記述ルールの記述様式は、例えばＡＰＩ記述ルール作成者／システム運用者４があらかじめ入力する。
ＳＴＥＰ９
図２の符号ｏに示すように、ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルール設定方式入力部１０３により事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを決定する。決定されたチェックポリシーは、チェックポリシー設定部１０６に送られる。
図２の符号ｏに示すように、ＡＰＩ記述ルール解析部１０５は、ＡＰＩ記述ルール設定方式入力部１０３により事前に規定された記述様式に従い、ＡＰＩ記述ルールを解析してチェックポリシーを決定する。決定されたチェックポリシーは、チェックポリシー設定部１０６に送られる。
ＳＴＥＰ１０
図２の符号ｐに示すように、ＡＰＩ記述ルール作成者／システム運用者４は、チェックポリシー設定部１０６で、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１０６は、チェックポリシーを準拠性チェック処理部１０８に反映する（図２の符号ｑ参照）。
図２の符号ｐに示すように、ＡＰＩ記述ルール作成者／システム運用者４は、チェックポリシー設定部１０６で、チェックポリシーに間違いのないことを確認する。チェックポリシーに間違いのないことが確認されると、チェックポリシー設定部１０６は、チェックポリシーを準拠性チェック処理部１０８に反映する（図２の符号ｑ参照）。
ＳＴＥＰ１１
一方、図２の符号ｒに示すように、ＯＡＳ作成部１１０は、作成したＯＡＳをＡＰＩ設計エディタ部１０７へ入力する。ＡＰＩ設計エディタ部１０７は、ＯＡＳとして作成された内容を表示する。
一方、図２の符号ｒに示すように、ＯＡＳ作成部１１０は、作成したＯＡＳをＡＰＩ設計エディタ部１０７へ入力する。ＡＰＩ設計エディタ部１０７は、ＯＡＳとして作成された内容を表示する。
ＳＴＥＰ１２
図２の符号ｓに示すように、ＡＰＩ設計エディタ部１０７は、ＯＡＳ作成部１１０により作成されたＯＡＳを表示させ、既存ＡＰＩ開発者５によるＡＰＩ設計書の設計および記載を支援する。
図２の符号ｓに示すように、ＡＰＩ設計エディタ部１０７は、ＯＡＳ作成部１１０により作成されたＯＡＳを表示させ、既存ＡＰＩ開発者５によるＡＰＩ設計書の設計および記載を支援する。
ＳＴＥＰ１２
図２の符号ｔに示すように、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書（ＯＡＳ）の入力を受け付け、入力されたＡＰＩ設計書（ＯＡＳ）をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する（図２の符号ｕ参照）。既存ＡＰＩ開発者５は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書（ＯＡＳ）を入力する。
図２の符号ｔに示すように、準拠性チェック処理部１０８は、既存ＡＰＩ開発者５からＡＰＩ設計書（ＯＡＳ）の入力を受け付け、入力されたＡＰＩ設計書（ＯＡＳ）をチェックポリシーに基づいてチェックし、チェックポリシーに沿っていない非準拠箇所を既存ＡＰＩ開発者５に通知する（図２の符号ｕ参照）。既存ＡＰＩ開発者５は、ＡＰＩ設計エディタ部１０７を用いてＡＰＩ設計書（ＯＡＳ）を入力する。
特に、図２の符号ｖに示すように、ＡＰＩ設計エディタ部１０７を経由して、準拠性チェック処理部１０８にＯＡＳを送ることで、準拠性チェック処理部１０８は、特定のＡＰＩ記述ルールへの準拠性チェックも確認可能である。なお、特定のＡＰＩ記述ルールは、ＡＰＩ記述ルール設定方式入力部１０３で入力されているＡＰＩ記述ルールの記述様式では準拠性チェックできないものを含む。
準拠性チェック処理部１０８は、既存ＡＰＩ開発者５に特定のＡＰＩ記述ルールに準拠した設計内容を提案する（図２の符号ｕ参照）。
準拠性チェック処理部１０８は、既存ＡＰＩ開発者５に特定のＡＰＩ記述ルールに準拠した設計内容を提案する（図２の符号ｕ参照）。
［ＯＡＳ作成部１１０動作］
図５を参照してＯＡＳ作成部１１０の動作を説明する。
ＯＡＳ作成部１１０（図２参照）は、ＡＰＩリクエスト−レスポンスキャプチャ部１０２（図２参照）でキャプチャされたＡＰＩリクエスト−レスポンス１２６のデータをパラメータ設定ロジックに従い、挿入値ファイル１２２へ反映させる。
図５に示す挿入値ファイル１２２において、
・host.yaml「host:」「basePath:」は、パラメータ設定ロジックに設定されている。このため、図５の符号ｚに示すように、・host.yamlは、ＡＰＩリクエスト１２４（図１３参照）の host: petstore-api.herokuapp.comそのままとなる。同様に、・basePath.yamlは、basePath: /Petとなる。
図５を参照してＯＡＳ作成部１１０の動作を説明する。
ＯＡＳ作成部１１０（図２参照）は、ＡＰＩリクエスト−レスポンスキャプチャ部１０２（図２参照）でキャプチャされたＡＰＩリクエスト−レスポンス１２６のデータをパラメータ設定ロジックに従い、挿入値ファイル１２２へ反映させる。
図５に示す挿入値ファイル１２２において、
・host.yaml「host:」「basePath:」は、パラメータ設定ロジックに設定されている。このため、図５の符号ｚに示すように、・host.yamlは、ＡＰＩリクエスト１２４（図１３参照）の host: petstore-api.herokuapp.comそのままとなる。同様に、・basePath.yamlは、basePath: /Petとなる。
ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンス１２６のデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定する。
一方、「・name_1.yaml」「・type_1.yaml」「・format_1.yaml」は、パラメータ設定ロジックに設定されていない。このため、図５の符号ａ１に示すように、・host.yamlは、ＡＰＩリクエスト−レスポンスの解析のみで機械的に設定できないパラメータ（一意に特定不可であるパラメータ）である。
この場合は、図５の符号ｂ１に示すように、パラメータ設定辞書１２３を参照して、「・name_1.yaml」「・type_1.yaml」「・format_1.yaml」に対して各パラメータを設定し、挿入値ファイル１２２に設計を反映する。
この場合は、図５の符号ｂ１に示すように、パラメータ設定辞書１２３を参照して、「・name_1.yaml」「・type_1.yaml」「・format_1.yaml」に対して各パラメータを設定し、挿入値ファイル１２２に設計を反映する。
上述したように、図５に示すパラメータ設定辞書１２３は、Wordに対応するType、format、maximum、およびminimumを有する。図５の符号ｂ１に示すように、Word「Birthday」が検索されると、Type 「integer」、format「int32」、maximum「99999999」、およびminimum「00」が参照され、挿入値ファイル１２２に設定される。すなわち、
・name_1.yaml
birthday:
・type_1.yaml
type: integer
・format_1.yaml
format: int32
が挿入値ファイル１２２に設定される。
・name_1.yaml
birthday:
・type_1.yaml
type: integer
・format_1.yaml
format: int32
が挿入値ファイル１２２に設定される。
ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンス１２６のデータと、パラメータ設定辞書１２３を参照して、暫定パラメータをより精度の高いパラメータに設定する。すなわち、一意にＯＡＳへ反映が難しいパラメータは、パラメータ設定辞書１２３を参照して、より精度の高いパラメータを設定する。
図６は、図５のＯＡＳ作成部１１０の動作により作成されたＯＡＳ仕様書１２７を示す図である。
図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）に挿入値ファイル１２２（図５参照）を挿入済のファイルを示す。
図６中の太文字は、ＡＰＩリクエスト−レスポンス１２６のキャプチャデータとパラメータ設定辞書１２３を参照し、雛形ファイル１２１（図３参照）へ設計を反映した箇所である。
例えば、図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）をもとに、
swagger: '2.0'
info:
version: 1.0.0
title: hogehoge
description: |
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
host: petstore-api.herokuapp.com
basePath: /pet
schemes:
- http
consumes:
- application/json
produces:
- application/json
paths:
/:
図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）に挿入値ファイル１２２（図５参照）を挿入済のファイルを示す。
図６中の太文字は、ＡＰＩリクエスト−レスポンス１２６のキャプチャデータとパラメータ設定辞書１２３を参照し、雛形ファイル１２１（図３参照）へ設計を反映した箇所である。
例えば、図６に示すＯＡＳ仕様書１２７は、雛形ファイル１２１（図３参照）をもとに、
swagger: '2.0'
info:
version: 1.0.0
title: hogehoge
description: |
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
host: petstore-api.herokuapp.com
basePath: /pet
schemes:
- http
consumes:
- application/json
produces:
- application/json
paths:
/:
続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
post:
parameters:
post:
parameters:
雛形ファイル１２１（図３参照）をもとに、
− name: A
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
in: body
− name: A
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
in: body
雛形ファイル１２１（図３参照）をもとに、
description: hogehogeschema:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
$ref: '#／definitions／A'
description: hogehogeschema:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
$ref: '#／definitions／A'
雛形ファイル１２１（図３参照）をもとに、
required: true
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
responses:
200:
required: true
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
responses:
200:
雛形ファイル１２１（図３参照）をもとに、
description: hogehoge
を記述する。
description: hogehoge
を記述する。
以上で、「post:」の記述とその挿入値ファイル１２２からのパラメータ挿入を終え、「name: A」についての定義を記述する。すなわち、
雛形ファイル１２１（図３参照）をもとに、
definitions:
A:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
type: object
雛形ファイル１２１（図３参照）をもとに、
definitions:
A:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
type: object
続いて、雛形ファイル１２１（図３参照）をもとに、
properties:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
name:
type: string
birthday:
type: integer
format: int32
上記パラメータは、一意にＯＡＳへ反映が難しいパラメータであり、パラメータ設定辞書１２３を参照して設定される。
properties:
を記述し、この記述に続いて、図５に示す挿入値ファイル１２２から下記パラメータを挿入する。
name:
type: string
birthday:
type: integer
format: int32
上記パラメータは、一意にＯＡＳへ反映が難しいパラメータであり、パラメータ設定辞書１２３を参照して設定される。
以上、ＨＴＴＰ形式のＲＥＳＴ ＡＰＩを用いたＯＡＳ作成部１１０の動作について説明した。
［変形例］
次に、変形例として、ＳＩＰ（Session Initiation Protocol）をＯＡＳ変換ロジックに変える場合について説明する。
次に、変形例として、ＳＩＰ（Session Initiation Protocol）をＯＡＳ変換ロジックに変える場合について説明する。
<雛形ファイル１２１Ａ>
図７は、ＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１Ａの一例を示す図である。図３の雛形ファイル１２１と同一部分には、同一パラメータを付している。
雛形ファイル１２１Ａは、ＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書を作成するための雛形である。
雛形ファイル１２１Ａには、ＡＰＩリクエスト−レスポンス１２６のパラメータに応じて変更する部分に、置換箇所を示す変換タグが記載される。
図７は、ＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＯＡＳ雛形設定部１１１が設定する雛形ファイル１２１Ａの一例を示す図である。図３の雛形ファイル１２１と同一部分には、同一パラメータを付している。
雛形ファイル１２１Ａは、ＡＰＩリクエスト−レスポンス１２６（図１３参照）の各パラメータの値に応じてＯＡＳ仕様書を作成するための雛形である。
雛形ファイル１２１Ａには、ＡＰＩリクエスト−レスポンス１２６のパラメータに応じて変更する部分に、置換箇所を示す変換タグが記載される。
ＯＡＳ作成部１１０（図５参照）は、雛形ファイル１２１Ａ記載の変換タグに対応した挿入値ファイル１２２Ａ（図８参照）を設定する。
図７に示す雛形ファイル１２１Ａは、
前記図３に示す雛形ファイル１２１の下記パラメータ
properties:
！！Conversion name_1:
！！Conversion type_1:
！！Conversion format_1
！！Conversion name_2:
！！Conversion type_2:
！！Conversion format_2:
が、下記パラメータ
properties:
from
！！Conversion type_1:
！！Conversion format_1
to
！！Conversion type_2:
！！Conversion format_2:
に置き換えられている。
前記図３に示す雛形ファイル１２１の下記パラメータ
properties:
！！Conversion name_1:
！！Conversion type_1:
！！Conversion format_1
！！Conversion name_2:
！！Conversion type_2:
！！Conversion format_2:
が、下記パラメータ
properties:
from
！！Conversion type_1:
！！Conversion format_1
to
！！Conversion type_2:
！！Conversion format_2:
に置き換えられている。
<挿入値ファイル１２２Ａ>
図８は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２Ａの一例を示す図である。
挿入値ファイル１２２Ａは、雛形ファイル１２１Ａ（図７参照）に反映するパラメータロジックを有するファイルである。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書を参照するなどして決定する。
図８に示す挿入値ファイル１２２Ａは、
・host.yaml
host: [REGISTER sip: ]
・method.yaml
− [REGESTER: post]
− [INVITE: get]
・type_1.yaml
[To: ]
を有する。
図８は、挿入値ファイル設定部１１２が設定する挿入値ファイル１２２Ａの一例を示す図である。
挿入値ファイル１２２Ａは、雛形ファイル１２１Ａ（図７参照）に反映するパラメータロジックを有するファイルである。なお、一意に特定できないパラメータ領域は、パラメータ設定辞書を参照するなどして決定する。
図８に示す挿入値ファイル１２２Ａは、
・host.yaml
host: [REGISTER sip: ]
・method.yaml
− [REGESTER: post]
− [INVITE: get]
・type_1.yaml
[To: ]
を有する。
図８の符号ｃ１に示すように、
・host.yaml
host: [REGISTER sip: ]は、網内プロキシに登録要求をするREGESTERメソッドによるリクエストのSIP URIをＨＴＴＰのhost部とする場合の例である。
・host.yaml
host: [REGISTER sip: ]は、網内プロキシに登録要求をするREGESTERメソッドによるリクエストのSIP URIをＨＴＴＰのhost部とする場合の例である。
図８の符号ｄ１に示すように、
・method.yaml
− [REGESTER: post]
− [INVITE: getは、SIP REGESTERをＨＴＴＰのPOSTメソッド、SIP INVITEをGETメソッドとする場合の例である。
・method.yaml
− [REGESTER: post]
− [INVITE: getは、SIP REGESTERをＨＴＴＰのPOSTメソッド、SIP INVITEをGETメソッドとする場合の例である。
図８の符号ｅ１に示すように、
・type_1.yaml
[To: ]は、SIP INVITEのTo:ヘッダの値を反映する場合の例である。
・type_1.yaml
[To: ]は、SIP INVITEのTo:ヘッダの値を反映する場合の例である。
以上、ＳＩＰをＨＴＴＰ形式のＲＥＳＴ ＡＰＩに変換する場合、ＳＩＰリクエスト−レスポンスの値を基に、ＨＴＴＰプロトコルへ変換するロジックを反映する。これにより、ＯＡＳ形式の仕様書を自動生成することが可能になる。
［構文的記述ルールの規定例］
次に、構文的記述ルールの規定例について説明する。
図９は、ＡＰＩ仕様書生成装置１００が規定する注釈様式に従って、構文的記述ルールを記載した例を示す図である。
次に、構文的記述ルールの規定例について説明する。
図９は、ＡＰＩ仕様書生成装置１００が規定する注釈様式に従って、構文的記述ルールを記載した例を示す図である。
図９の例では、ＡＰＩのリソース名、パラメータ名に、アプリが動作する上でバグの原因となるおそれのある文字「％」，「：」，「￥」，「￥￥」, 「＼（バックスラッシュ）」の使用を禁止するルールが記載されている。
具体的には、図９の符号ｆ１に示すように、“@NGcheck\Resource”は、ＡＰＩ仕様書生成装置１００が規定した記述様式であり、ＡＰＩ設計書内の各ＡＰＩのリソース名内部で特定の記述等がされた場合にエラーを出力するルール（ポリシー）である。また、図９の符号ｇ１に示すように、“@NGcheck\Parameters”は、各ＡＰＩのパラメータ名に特定の文字、文字列が存在する場合にエラー情報を出力するルール（ポリシー）である。また、図９の符号ｈ１に示すように、使用してはいけない文字、文字列が正規表現等で記述されている。
具体的には、図９の符号ｆ１に示すように、“@NGcheck\Resource”は、ＡＰＩ仕様書生成装置１００が規定した記述様式であり、ＡＰＩ設計書内の各ＡＰＩのリソース名内部で特定の記述等がされた場合にエラーを出力するルール（ポリシー）である。また、図９の符号ｇ１に示すように、“@NGcheck\Parameters”は、各ＡＰＩのパラメータ名に特定の文字、文字列が存在する場合にエラー情報を出力するルール（ポリシー）である。また、図９の符号ｈ１に示すように、使用してはいけない文字、文字列が正規表現等で記述されている。
このように、ＡＰＩのリソース名、パラメータ名に、アプリ動作する上でバグの原因となるおそれのある「%」, 「:」, 「\」, 「＼」の使用を禁止する場合は、ＡＰＩ仕様書生成装置１００が指定する記述様式を用いて正規表現等を活用して記述したファイルをＡＰＩ記述ルール入力部１０４（図２参照）にインポートする（図９の符号ｉ１参照）。
準拠性チェック処理部１０８（図２参照）は、記述された内容に従って、準拠性チェックポリシーを規定する。
図９の符号ｊ１に示すように、ＡＰＩ設計エディタ部１０７（図２参照）は、記載されたＡＰＩ仕様を、事前に規定されたチェックポリシーに従って準拠性確認をし、その結果を既存ＡＰＩ開発者５に通知する。通知形式は、ＡＰＩ設計エディタ部１０７がリアルタイムに通知を行う。
図９の符号ｊ１に示すように、ＡＰＩ設計エディタ部１０７（図２参照）は、記載されたＡＰＩ仕様を、事前に規定されたチェックポリシーに従って準拠性確認をし、その結果を既存ＡＰＩ開発者５に通知する。通知形式は、ＡＰＩ設計エディタ部１０７がリアルタイムに通知を行う。
［メソッド使用ルールの規定例］
次に、メソッド使用ルールの規定例について説明する。
図１０は、ＡＰＩ記述ルールを表にして示す図である。図１０に示す表は、ＡＰＩ記述ルールとして各メソッドの使用用途を規定する。
図１０の表に示すように、ＣＲＵＤ（Create，Read，Update，Delete）毎に、メソッド名（ＰＯＳＴ，ＧＥＴ，ＰＵＴ，ＤＥＬＥＴＥ）と、対応する用途を規定する。
ＡＰＩ記述ルールとして各メソッドの使用用途を図１０の表に規定したと仮定する。例えば、リソースを新規に作成／更新／削除するようなＡＰＩにもかかわらず、「ＧＥＴ」を用いているかを確認する。図１０の表で規定したルールに反して用途に合っていないメソッドが使われている場合にエラーを出力する。
次に、メソッド使用ルールの規定例について説明する。
図１０は、ＡＰＩ記述ルールを表にして示す図である。図１０に示す表は、ＡＰＩ記述ルールとして各メソッドの使用用途を規定する。
図１０の表に示すように、ＣＲＵＤ（Create，Read，Update，Delete）毎に、メソッド名（ＰＯＳＴ，ＧＥＴ，ＰＵＴ，ＤＥＬＥＴＥ）と、対応する用途を規定する。
ＡＰＩ記述ルールとして各メソッドの使用用途を図１０の表に規定したと仮定する。例えば、リソースを新規に作成／更新／削除するようなＡＰＩにもかかわらず、「ＧＥＴ」を用いているかを確認する。図１０の表で規定したルールに反して用途に合っていないメソッドが使われている場合にエラーを出力する。
図１１は、ＡＰＩ仕様書生成装置１００が規定する記述様式に従って、メソッド使用ルールを記載した例を示す図である。
図１１の符号ｋ１に示すように、“@NGcheck\Api”は、一つのエンドポイント毎のＡＰＩに関する設計（概要やメソッド）において、特定の条件に当てはまる記述が存在する場合にエラーを出力するルール（ポリシー）である。図１１の符号ｌ１に示すように、ＡＰＩ仕様書生成装置１００が規定した記述様式でエラーを出力するポリシーを記載する。例えば、ＡＰＩの説明文（description部）に「更新」、「create」、「追加」、「add」、「削除」、「delete」という記載があり、かつ、ＧＥＴメソッドを使用している場合、エラーを出力する。より具体的には、ＡＰＩ設計書において、ある行にＧＥＴメソッドを使用することが記載されており、その後の行のＡＰＩの説明文に“Create”の記述がある場合を想定する。このＡＰＩ設計書は、リソースを新規に作成するＡＰＩにもかかわらずＧＥＴを用いている。したがって、このＡＰＩ設計書をＡＰＩ仕様書生成装置１００に入力した場合、用途に合っていないメソッドが使われている旨のエラー情報が出力される。
ＡＰＩ仕様書生成装置１００が規定する記述様式に沿った設計、または、一般的なプログラミング言語で、エラー検出のロジックを組むことで、ルール違反したメソッドの使用をチェックすることが可能になる。
ＡＰＩ仕様書生成装置１００が規定する記述様式に沿った設計、または、一般的なプログラミング言語で、エラー検出のロジックを組むことで、ルール違反したメソッドの使用をチェックすることが可能になる。
以上説明したように、本実施形態のＡＰＩ仕様書生成装置１００（図１参照）は、ＯＡＳ仕様書１２７を作成する際の雛形ファイル１２１をあらかじめ設定するＯＡＳ雛形設定部１１１と、ＯＡＳ仕様書１２７で用いるパラメータ設定ロジックを記述する挿入値ファイル１２２を設定する挿入値ファイル設定部１１２と、ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ部１０２と、キャプチャしたＡＰＩリクエスト−レスポンスデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映してパラメータを設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成するＯＡＳ作成部１１０と、を備える。
この構成により、ＡＰＩリクエスト−レスポンス１２６をもとに低コストでデータ型や値の範囲まで反映するＯＡＳ仕様書１２７を作成できる。また、各種プロトコルの値から、ＯＡＳにパラメータをどのように設定するかを記述するパラメータ設定ロジックも、システム運用者にてカスタマイズ可能である。さらに、独自パラメータやＨＴＴＰ以外のプロトコルもＯＡＳ仕様書の対象にすることができる。
本実施形態では、ＡＰＩ仕様書生成装置１００は、一意にＯＡＳ仕様書１２７へ反映が難しいパラメータを登録するパラメータ設定辞書１２３を格納するパラメータ設定辞書格納部１１３を備え、ＯＡＳ作成部１１０は、キャプチャしたＡＰＩリクエスト−レスポンス１２６のデータと、挿入値ファイル１２２の参照結果とを雛形ファイル１２１に反映して暫定パラメータを設定するとともに、キャプチャしたＡＰＩリクエスト−レスポンス１２６のデータと、パラメータ設定辞書を参照して、暫定パラメータをより精度の高いパラメータに設定し、設定したパラメータをもとにＯＡＳ仕様書１２７を作成する。
このようにすることで、ＡＰＩリクエスト−レスポンス１２６とＡＰＩパラメータ設定辞書１２３を参照して、一意に特定不可であるパラメータも高精度で設計可能となる。このため、ＯＡＳ仕様書１２７の作成および修正稼働を削減することができる。
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
１０ ＲＥＳＴ ＡＰＩ
１１ 既存ＡＰＬ
１５ Ｌ２スイッチ
２０ ＡＰＩ提供装置（既存機能）
１００ ＡＰＩ仕様書生成装置
１０１ ＡＰＩリクエスト−レスポンスＩＦ部
１０２ ＡＰＩリクエスト−レスポンスキャプチャ部（ＡＰＩリクエスト−レスポンスキャプチャ手段）
１０３ ＡＰＩ記述ルール設定方式入力部
１０４ ＡＰＩ記述ルール入力部
１０５ ＡＰＩ記述ルール解析部
１０６ チェックポリシー設定部
１０７ ＡＰＩ設計エディタ部
１０８ 準拠性チェック処理部
１１０ ＯＡＳ作成部（ＯＡＳ作成手段）
１１１ ＯＡＳ雛形設定部（ＯＡＳ雛形設定手段）
１１２ 挿入値ファイル設定部（挿入値ファイル設定手段）
１１３ パラメータ設定辞書格納部
１２１，１２１Ａ 雛形ファイル
１２２，１２２Ａ 挿入値ファイル
１２３ パラメータ設定辞書
１２４ ＡＰＩリクエスト
１２５ ＡＰＩレスポンス
１２６ ＡＰＩリクエスト−レスポンス
１２７ ＯＡＳ仕様書
１１ 既存ＡＰＬ
１５ Ｌ２スイッチ
２０ ＡＰＩ提供装置（既存機能）
１００ ＡＰＩ仕様書生成装置
１０１ ＡＰＩリクエスト−レスポンスＩＦ部
１０２ ＡＰＩリクエスト−レスポンスキャプチャ部（ＡＰＩリクエスト−レスポンスキャプチャ手段）
１０３ ＡＰＩ記述ルール設定方式入力部
１０４ ＡＰＩ記述ルール入力部
１０５ ＡＰＩ記述ルール解析部
１０６ チェックポリシー設定部
１０７ ＡＰＩ設計エディタ部
１０８ 準拠性チェック処理部
１１０ ＯＡＳ作成部（ＯＡＳ作成手段）
１１１ ＯＡＳ雛形設定部（ＯＡＳ雛形設定手段）
１１２ 挿入値ファイル設定部（挿入値ファイル設定手段）
１１３ パラメータ設定辞書格納部
１２１，１２１Ａ 雛形ファイル
１２２，１２２Ａ 挿入値ファイル
１２３ パラメータ設定辞書
１２４ ＡＰＩリクエスト
１２５ ＡＰＩレスポンス
１２６ ＡＰＩリクエスト−レスポンス
１２７ ＯＡＳ仕様書
Claims (5)
- 既存ＡＰＩ（Application Program Interface）の仕様を変換して標準仕様のＯＡＳ（Open API spec）仕様書を生成するＡＰＩ仕様書生成装置であって、
前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定部と、
前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定部と、
ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ部と、
キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成部と、を備える
ことを特徴とするＡＰＩ仕様書生成装置。 - 一意にＯＡＳ仕様書へパラメータを登録するパラメータ設定辞書を格納するパラメータ設定辞書格納部をさらに備え、
前記ＯＡＳ作成部は、
キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映して暫定パラメータを設定するとともに、
キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記パラメータ設定辞書を参照して、前記暫定パラメータを、当該暫定パラメータよりも精度の高いパラメータに設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成する
ことを特徴とする請求項１に記載のＡＰＩ仕様書生成装置。 - アプリケーションプログラミングインタフェースを設計する際のルールを記述したＡＰＩ記述ルールを入力するＡＰＩ記述ルール入力部と、
前記ＡＰＩ記述ルールを解析してチェックポリシーを作成するＡＰＩ記述ルール解析部と、
前記チェックポリシーに基づいて前記ＡＰＩ記述ルールに準拠していることをチェックする準拠性チェック処理部と、をさらに備え、
前記ＯＡＳ作成部は、
作成した前記ＯＡＳ仕様書を前記準拠性チェック処理部に送り、
前記準拠性チェック処理部は、
前記ＯＡＳ作成部から送られた前記ＯＡＳ仕様書をもとに、前記ＡＰＩ記述ルールへの準拠性をチェックする
ことを特徴とする請求項１に記載のＡＰＩ仕様書生成装置。 - 既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置が、
前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するステップと、
前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定するステップと、
ＡＰＩリクエストとそのレスポンスをキャプチャするステップと、
キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するステップと、を実行する
ことを特徴とするＡＰＩ仕様書生成方法。 - 既存ＡＰＩの仕様を変換して標準仕様のＯＡＳ仕様書を生成するＡＰＩ仕様書生成装置としてのコンピュータを、
前記ＯＡＳ仕様書を作成する際の雛形ファイルをあらかじめ設定するＯＡＳ雛形設定手段、
前記ＯＡＳ仕様書で用いるパラメータ設定ロジックを記述する挿入値ファイルを設定する挿入値ファイル設定手段、
ＡＰＩリクエストとそのレスポンスをキャプチャするＡＰＩリクエスト−レスポンスキャプチャ手段、
キャプチャしたＡＰＩリクエスト−レスポンスデータと、前記挿入値ファイルの参照結果とを前記雛形ファイルに反映してパラメータを設定し、設定した前記パラメータをもとに前記ＯＡＳ仕様書を作成するＯＡＳ作成手段、
として機能させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018148615A JP2020024567A (ja) | 2018-08-07 | 2018-08-07 | Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム |
| PCT/JP2019/030228 WO2020031845A1 (ja) | 2018-08-07 | 2019-08-01 | Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018148615A JP2020024567A (ja) | 2018-08-07 | 2018-08-07 | Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2020024567A true JP2020024567A (ja) | 2020-02-13 |
Family
ID=69414186
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018148615A Pending JP2020024567A (ja) | 2018-08-07 | 2018-08-07 | Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP2020024567A (ja) |
| WO (1) | WO2020031845A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111399900A (zh) * | 2020-03-10 | 2020-07-10 | 山东汇贸电子口岸有限公司 | 一种基于python与正则表达式的API文档自动生成方法及系统 |
| US20220035600A1 (en) * | 2019-05-17 | 2022-02-03 | Google Llc | API Specification Generation |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9954746B2 (en) * | 2015-07-09 | 2018-04-24 | Microsoft Technology Licensing, Llc | Automatically generating service documentation based on actual usage |
| JP6733473B2 (ja) * | 2016-09-30 | 2020-07-29 | 富士通株式会社 | 情報処理装置、仕様書作成方法及び仕様書作成プログラム |
| US9936005B1 (en) * | 2017-07-28 | 2018-04-03 | Kong Inc. | Systems and methods for distributed API gateways |
-
2018
- 2018-08-07 JP JP2018148615A patent/JP2020024567A/ja active Pending
-
2019
- 2019-08-01 WO PCT/JP2019/030228 patent/WO2020031845A1/ja active Application Filing
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220035600A1 (en) * | 2019-05-17 | 2022-02-03 | Google Llc | API Specification Generation |
| CN111399900A (zh) * | 2020-03-10 | 2020-07-10 | 山东汇贸电子口岸有限公司 | 一种基于python与正则表达式的API文档自动生成方法及系统 |
| CN111399900B (zh) * | 2020-03-10 | 2023-04-07 | 山东汇贸电子口岸有限公司 | 一种基于python与正则表达式的API文档自动生成方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020031845A1 (ja) | 2020-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100399323C (zh) | 用于检验扩展标记语言文件的有效性的装置和方法 | |
| US11048682B2 (en) | Custom lightning connect adapter for google sheets web-based spreadsheet program | |
| US9734044B2 (en) | Automatic test case generation | |
| US9594802B2 (en) | Graphical modeling of database query statements | |
| US8561088B2 (en) | Registering network applications with an API framework | |
| US20070067512A1 (en) | Method, system and software arrangement for processing a device support file for a field device | |
| US20070198457A1 (en) | Accessing and manipulating data in a data flow graph | |
| CN114981775B (zh) | 用于api综合管理的基于云的api元数据管理方法及系统 | |
| WO2020031845A1 (ja) | Ａｐｉ仕様書生成装置、ａｐｉ仕様書生成方法、およびプログラム | |
| Bojinov | RESTful Web API Design with Node. js 10: Learn to create robust RESTful web services with Node. js, MongoDB, and Express. js | |
| US10606569B2 (en) | Declarative configuration elements | |
| KR100762712B1 (ko) | 규칙기반의 전자문서 변환방법 및 그 시스템 | |
| Bojinov | RESTful Web API Design with Node. js | |
| CN111510483B (zh) | 芯片测试中不同网络域之间的配置同步系统、方法及装置 | |
| US11144287B2 (en) | Compile time validation of programming code | |
| JP2019028723A (ja) | 設計確認装置及び設計確認方法 | |
| US11115279B2 (en) | Client server model for multiple document editor | |
| JP2008210214A (ja) | 情報処理装置、通信制御処理関数追加方法、及び、通信制御処理関数追加プログラム | |
| US8825686B2 (en) | Expression evaluation over multiple data models | |
| Barakat et al. | IDLGen: Automated Code Generation for Inter-parameter Dependencies in Web APIs | |
| CN110633158B (zh) | 在过程建模中实现同步可编辑信号的方法、系统和介质 | |
| Kelly | Aggregating Private and Public Web Archives Using the Mementity Framework | |
| Troelsen et al. | RESTful Services with ASP. NET Core | |
| CN114500679B (zh) | can协议转换方法、装置、电子设备和存储介质 | |
| CN115659471B (zh) | 基于物模型及模型编码的数据融合方法 |