JP2018142271A - Ａｐｉ規約チェック装置、ａｐｉ規約チェック方法、およびプログラム - Google Patents

Abstract

【課題】ＡＰＩ仕様書およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかをチェックできるＡＰＩ規約チェック装置、ＡＰＩ規約チェック方法、およびプログラムを提供する。
【解決手段】ＡＰＩ規約チェック装置１００は、ＡＰＩ仕様書およびＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するＡＰＩ仕様書アダプタ部１１０と、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納部１２０と、ルールファイルを参照して、要求項目に対してＡＰＩ規定に合わない箇所をチェックするチェック実行部１３０と、チェック結果の箇所と内容を登録するチェック結果格納部１４０と、チェック結果をＡＰＩ設計者にアウトプットする結果出力部１５０と、を備える。
【選択図】図１

Description

本発明は、ＡＰＩ規約チェック装置、ＡＰＩ規約チェック方法、およびプログラム
に関する。

各事業者がサービスを管理するためのＡＰＩ（Application Program Interface）をウェブ上にて提供しており、ユーザはＡＰＩを呼び出すソフトウェアを通じてサービスを構築・運用している。ＡＰＩの仕様（ＡＰＩの名称、ＵＲＬ（Uniform Resource Locator）、パラメータ等）は、各事業者が規定しており、ユーザは当該規定に従ってＡＰＩを使用する。

事業者によるＡＰＩ提供が増えてきており、単一の事業者が複数のサービス用ＡＰＩを提供したり、複数事業者で同様のサービス用ＡＰＩが提供されるのが一般的になりつつある。ユーザは、それらのＡＰＩの仕様／（「／」は、「および／または」、を表記する。以下同様。）設計をそれぞれ理解して使い分ける必要があり、負担がかかっている。ＡＰＩ設計の違いはＡＰＩ普及の阻害要因となっている。
そのため、事業者内／事業者間にて、ＡＰＩの設計を合わせていく動きが活発になっている。これらの取り組みにおいては、事業者外のガバナンス団体もしくは事業者内のガバナンス組織において、個別の組織／設計者が設計したＡＰＩをレビューし、規約に沿っているか確認することが一般的である。
しかしながら、多くのＡＰＩ設計ルール（プロトコルレベル〜パラメータレベル）があり、規約に沿っているかをすべて人手でチェックするのが困難である。

非特許文献１には、語句を入力すると、最小単位に分割してそれぞれでネーミング（英語に変換）する技術が記載されている。非特許文献１に記載の「メソッド名等のネーミングサービス」は、内部に辞書を持ち、日本語を入れるとネーミングの候補を教えてくれる。また、語句を入力すると、最小単位に分割してそれぞれでネーミング（英語に変換）してくれる。変換結果は、snake_case や camelCase で表示可能である。学習機能があり、変換パターンをカスタマイズして定義できる（アカウントごと）。しかし、語句単位の単純変換はできるが、ＡＰＩのように階層構造を持つ複数の要素の考慮や、変換パターンをルール化しエクスポートして共有する等の使い方はできない。

非特許文献２には、コーディング規約のチェックツール(Eclipse plugin)が記載されている。非特許文献２に記載の技術は、ソースコードにおける中括弧や、空白スペースの記述位置などコーディングスタイルに関する指摘のほか、クラス名、定数、変数、メソッド名などの命名規則がコーディング規約（あるいは命名規約）として定義された規則に従い、正しく記述されているかどうかをチェックする。非特許文献２に記載のコーディング規約のチェックツールは、入力途中でチェック可能である。Sun（登録商標）のコーディング規約に基づいたルール群がデフォルトで提供される。ルール群はＸＭＬ（Extensible Markup Language）で記述されていて、カスタマイズ可能という特徴がある。

メソッド名等のネーミングサービス,［online］,［平成２９年２月１５日検索］,インターネット 〈URL:https://codic.jp/〉 コーディング規約のチェックツール(Eclipse plugin),［online］,［平成２９年２月１５日検索］,インターネット 〈URL:http://checkstyle.sourceforge.net/〉

上述したように、人手でチェックするのが大変である。このため、それを解決する関連技術としてはcodic, checkstyleがあるが、それでは下記のようなチェックができない。
（１）ＵＲＩ（Uniform Resource Identifier）の階層制限とリソース／パラメータ構成（後記）
（２）ＡＰＩ名とそのＡＰＩで扱うリソース名、パラメータ名の関係（後記）
（３）レスポンスの型とリソース名の関係（単数形／複数形等）（後記）
また、規約の数が増えるにつれて、規約自体の作成と整合性チェックが困難になるが、既存技術によるサポートはない。

このような背景に鑑みて本発明がなされたのであり、本発明は、ＡＰＩ仕様書およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかをチェックできるＡＰＩ規約チェック装置、ＡＰＩ規約チェック方法、およびプログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、設計したＡＰＩが規約に沿っているかをチェックするＡＰＩ規約チェック装置であって、ＡＰＩ仕様書および前記ＡＰＩＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するＡＰＩ仕様書アダプタ部と、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納部と、前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するチェック実行部と、を備えることを特徴とするＡＰＩ規約チェック装置とした。

また、請求項７に記載の発明は、設計したＡＰＩがＡＰＩ規約に沿っているかをチェックするＡＰＩ規約チェック装置が、前記ＡＰＩ仕様書および前記ＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するステップと、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するステップと、前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するステップと、を実行することを特徴とするＡＰＩ規約チェック方法とした。

また、請求項８に記載の発明は、設計したＡＰＩ（Application Program Interface）がＡＰＩ規約に沿っているかをチェックするＡＰＩ規約チェック装置としてのコンピュータを、ＡＰＩ仕様書および前記ＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するＡＰＩ仕様書アダプタ手段、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納手段、前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するチェック実行手段、として機能させるためのプログラムとした。

このようにすることで、ＡＰＩ仕様書およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかをチェックできる。このため、ＡＰＩ設計者および、ルールファイルをインプットするＡＰＩ統制者によるＡＰＩ規約チェックの簡易化が可能になる。

また、請求項２に記載の発明は、前記ルールファイル格納部は、前記ルールファイルとして、チェック対象となる項目を指定するチェック対象定義ルールファイル、ＡＰＩ名、リソース名、パラメータ名に用いる類義語を定義する類義語定義ルールファイル、ホスト名、ＡＰＩ名、バージョン名の順番および有無を定義するＵＲＩ構成定義ルールファイル、ＡＰＩ名の候補および／または命名ルール、並びに前記ＡＰＩ名で扱うリソース名を定義するＡＰＩ名定義ルールファイル、リソース名の候補および、前記リソース名のリソースに関する操作一覧とインプット、アウトプットとを規定するリソース定義ルールファイル、リソース定義に用いるデータスキーマを規定するスキーマ定義ルールファイルのうち、少なくともいずれか１つを含むことを特徴とする請求項１に記載のＡＰＩ規約チェック装置とした。

このようにすることで、チェック実行部によって、対応する各ルールファイルが参照されて、ＡＰＩに特有のＵＲＬ、リソース名、パラメータ名の相互の関係が加味され、設計したＡＰＩが規約に沿っているかをチェックできる。

また、請求項３に記載の発明は、前記ルールファイル格納部が、前記ルールファイルの定義を標準ＡＰＩ仕様書のフォーマットに合わせることを特徴とする請求項１または請求項２に記載のＡＰＩ規約チェック装置とした。

このようにすることで、同じロジックを用いて、標準ＡＰＩ仕様書をもとにＡＰＩ規約を定義するルールファイル自体のチェックも可能となる。また、一部の規約チェック機能は、ルールファイルに対しても適用できるため、ＡＰＩ規約作成自体もサポートが可能になる。これにより、ルールファイルをインプットするＡＰＩ統制者の稼働を削減することができ、ＡＰＩ規約の精度向上につながる。
また、ＡＰＩ規約が変わった場合でも、上記ルールファイルを更新するだけで自動チェックが可能になる。

また、請求項４に記載の発明は、前記チェック実行部が、レスポンスの型とリソース名の関係、および前記レスポンスの型と前記リソース名が、単数形または複数形であることのチェックを行うことを特徴とする請求項１に記載のＡＰＩ規約チェック装置とした。

このようにすることで、表層の名前合わせだけでなく、レスポンスの型とリソース名の関係、単数形または複数形を相互の関係のルールとしてその記述をチェックでき、またバージョン管理することができる。その結果、ＡＰＩ設計の精度向上を図ることができる。

また、請求項５に記載の発明は、前記チェック実行部が、前記ＡＰＩ規約としてＵＲＩの階層の数が制限される場合、当該制限により影響があるリソースの構造と前記パラメータ名のチェックを行うことを特徴とする請求項１に記載のＡＰＩ規約チェック装置とした。

このようにすることで、ＵＲＩの階層の数の制限で影響があるリソースの構造とパラメータ名についてもチェックを行うことができるとともに、リソース階層の数を変更した場合であってもリソースの構造とパラメータ名のチェックすることができる。

また、請求項６に記載の発明は、前記チェック実行部は、ＵＲＩ構成のチェックを行うＵＲＩ構成チェック部、前記ＡＰＩ名のチェックを行うＡＰＩ名チェック部、前記リソース名のチェックを行うとともに、前記リソース名の単数形および／または複数形規約をチェックするリソース名チェック部、前記パラメータ名のチェックを行うパラメータ名チェック部、前記ＡＰＩ名と前記リソース名との対応チェックを行うＡＰＩ名−リソース名対応チェック部、前記リソース名と前記パラメータ名との対応チェックを行うリソース名−パラメータ名対応チェック部、リソース階層の数をチェックするリソース階層数チェック部のうち、少なくともいずれか１つを備えることを特徴とする請求項１に記載のＡＰＩ規約チェック装置とした。

このようにすることで、チェック実行部の各チェック部が、対応する各ルールファイルを参照して、ＡＰＩに特有のＵＲＬ、リソース名、パラメータ名の相互の関係を加味して、設計したＡＰＩが規約に沿っているかをチェックできる。

本発明によれば、ＡＰＩ仕様書およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかをチェックできるＡＰＩ規約チェック装置、ＡＰＩ規約チェック方法、およびプログラムを提供することができる。

本発明の実施形態に係るＡＰＩ規約チェック装置を示す構成図である。 本発明の実施形態に係るＡＰＩ規約チェック装置の各機能部によって参照されるチェック対象定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のチェック対象定義ルールファイルを参照した各機能部が実行する処理を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のＵＲＩ構成チェック部におけるＵＲＩ構成のチェックの概要を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のＵＲＩ構成チェック部におけるＵＲＩ構成のチェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ＵＲＩ構成定義ルールファイルのうち、（Ａ）ＡＰＩ名はホスト名の後である場合の一例と、（Ｂ）ＡＰＩ名はホスト名の前である場合の一例とを示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のＡＰＩ名チェック部のＡＰＩ名チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのうち、ＡＰＩ名定義ルールファイルと類義語定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース名チェック部のリソース名チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのうち、リソース定義ルールファイルと類義語定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース名チェック部のリソース名チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのチェック対象定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース名チェック部のリソース名チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのうち、リソース定義ルールファイルと類義語定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のパラメータ名チェック部のパラメータ名のチェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのうち、リソース定義ルールファイルとスキーマ定義ルールファイルと類義語定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のパラメータ名チェック部の単数形／複数形規約チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのうち、チェック対象定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース名−パラメータ名対応チェック部のリソース名とパラメータ名の対応チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、リソース名−パラメータ名対応チェック部のルールファイルのうち、リソース定義ルールファイルおよびスキーマ定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース階層数チェック部におけるリソース名の階層数チェックの詳細を説明する図であり、（ａ）は、ＡＰＩ仕様書の一例を示す図、（ｂ）は、ルールファイル格納部のルールファイルのチェック対象定義ルールファイルの一例を示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置のリソース階層数チェック部の階層数変更提案の詳細を説明する図であり、（ａ）は、リソース名に階層の数ポリシーに反する部分を有するリソース定義ルールファイル１２５を示す図、（ｂ）は、リソース名に階層の数ポリシーに反する部分を有するスキーマ定義ルールファイルを示す図である。 本発明の実施形態に係るＡＰＩ規約チェック装置の低階層化する場合の、リソース階層数チェック部の階層数変更提案の詳細を説明する図であり、（ａ）は、低階層化されたリソース定義ルールファイル１２５を示す図、（ｂ）は、低階層化されたスキーマ定義ルールファイル１２６を示す図である。 ＡＰＩの用語の定義を説明する図である。 ＵＲＩの階層制限とリソース／パラメータ構成を示す図である。 ＡＰＩ名とリソース名、パラメータ名の関係を示す図である。 レスポンスの型とリソース名の関係を示す図であり、（ａ）はＡＰＩのリソース名“products”の場合を示し、（ｂ）は（ａ）の“products”の場合のレスポンスを示し、（ｃ）はＡＰＩのリソース名“profile”の場合を示し、（ｄ）は“profile”の場合のレスポンスを示す図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるＡＰＩ規約チェック装置等について説明する。
ＡＰＩ仕様書、およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかを自動的にチェックするＡＰＩ規約チェック方法に適用した例である。

（背景説明）
まず、ＡＰＩの用語の定義について説明する。
図１６は、ＡＰＩの用語の定義を説明する図である。図１６（ａ）は、ＨＴＴＰメソッド名およびＵＲＩ（Uniform Resource Identifier）で示されるリクエスト、図１６（ｂ）は、このリクエストに対するレスポンスを示す。
ＷｅｂＡＰＩで機能を公開しているサーバに対して、インターネットなどの通信ネットワークを通じて依頼内容をＨＴＴＰリクエストの形で送信すると、処理結果がＨＴＴＰレスポンスの形で送られてくる。送受信されるデータの形式は、ＡＰＩによって様々である。

図１６（ａ）に示すように、ＡＰＩのリクエストは、ＧＥＴ，ＰＯＳＴ，ＰＵＴ，ＤＥＬＥＴＥなどの操作／オペレーション（動詞）で示されるメソッド名と、ＨＴＴＰなどのハイパーテキスト転送プロトコルおよびホスト名と、ＡＰＩ名と、バージョン名と、リソース名およびそのＩＤと、からなる。「/」は、ホスト名、ＡＰＩ名、バージョン名、リソース名とそのＩＤとを区切る区切記号である。
図１６（ａ）の場合、リソースの階層は１層であり、ホスト名「api.sample.com」、ＡＰＩ名「customerManagement」、バージョン名「v1」、リソース名「customer」とそのＩＤ「10」が記述されている。上記ホスト名、ＡＰＩ名、バージョン名、リソース名とそのＩＤは、リクエストのＵＲＩである。なお、図１６（ａ）では、キャメルケースで記載されているが、スネークケースで記載される場合もある（以下同様）。

図１６（ｂ）は、図１６（ａ）のリクエストに対するレスポンスの記載を示している。
図１６（ｂ）に示すレスポンスは、下記構成である。
customer : {
id: 10,
name: “Taro Yamada”,
:
}
リソース「customer」(“顧客”の意)の構成要素として、そのＩＤ「id: 10」、顧客名「name: “Taro Yamada”」が記載される。上記「id」と「name」はパラメータ名と呼ばれる。

［リソースの階層制限とリソース／パラメータ構成］
図１７は、リソースの階層制限とリソース／パラメータ構成を示す図である。
図１７（ａ）に示すように、ＡＰＩのリクエストは、ＧＥＴ，ＰＯＳＴ，ＰＵＴ，ＤＥＬＥＴＥなどのメソッド名と、ＨＴＴＰなどのハイパーテキスト転送プロトコルおよびホスト名と、階層順に記述されるリソース名およびそのＩＤと、からなる。「/」は、ドメイン名、リソース名とそのＩＤとを区切る。
図１７（ａ）の場合、ＵＲＩの階層は２階層であり、階層１のリソース名とそのＩＤ「user/12(12はidを示す)」に、階層２のリソース名とそのＩＤ「article/40(40はidを示す)」が記述されている。

ＡＰＩ規約としてＵＲＩの階層の数を制限したい場合もあり、制限によってはリソースの構造とパラメータ名に影響が及ぶ場合がある。
例えば、図１７（ｂ）に示すように、ある事業者のＡＰＩ規約（ルールファイル）では、ＵＲＩは１階層のみであるとする。この場合、このＡＰＩ規約に沿うために、図１７（ａ）に示すＡＰＩを、クエリで指定する案１か、メソッド名をＧＥＴからＰＯＳＴにし、ＰＯＳＴのＢｏｄｙに記載する案２がある。なお、案１のリソース名「article」とリソース名「userId」を繋ぐ「?」はクエリパラメータである。

図１７（ｃ）に示す階層１のリソース名とそのＩＤ「User/12(12はidを示す)」と、階層２のリソース名とそのＩＤ「article/40(40はidを示す)」を、１階層で記載するには、図１６（ｃ）の白文字矢印の右側に示すように、リソース名「article/id:/title:/userId」（userId がarticleに所属する）と記載する。
ここで、リソースarticleのパラメータとして“userId”, “username”等はもともと定義されていないが、こうした制約が存在した場合には規約違反ではないと判定できる必要がある。また、クエリで指定する上記案１か、ＰＯＳＴにしてＢｏｄｙに記載する上記案２という回避策があるが、どちらのポリシーを取るかが全体として揃っている必要がある。

［ＡＰＩ名とリソース名、パラメータ名の関係］
図１８は、ＡＰＩ名とリソース名、パラメータ名の関係を示す図である。
図１８に示すように、ＡＰＩは、ＡＰＩ名（例えばcustomerManagement）と、その下にリソース名（customer，customerAccount，customerPaymentMean，…）と、その下にパラメータ名（id，name，contactMedium，customerAccount，…）と、の階層構造をもつ。

ＡＰＩ名、リソース名、パラメータ名には、それぞれ対応関係があるため、単体のネーミングとしては問題なくても、構造の中では不適切な場合がある。また、これらの対応関係を考慮することで、より精度の高い提案（サジェスト）が可能になる。例えば、リソース名として “client”と入力している場合、単体のネーミングとしては問題ない。しかし、パラメータ名にcontactMediumやcustomerAccountを定義しているので、リソース名が“client”であることは不適切であり、この場合のリソース名は“customer”を意味している可能性が高いなどである。

［レスポンスの型とリソース名の関係］
図１９は、レスポンスの型とリソース名の関係を示す図である。
レスポンスの型によって、リソース名に制約を持たせたい場合が存在する。例えば、レスポンスがリストの場合、ＡＰＩのリソース名を複数形にする等である。
図１９（ａ）に示すリソース名“products”を取得する例では、そのレスポンスが図１９（ｂ）に示すように、
products: [
{id: 1, name: “Abcde Z1f”, …},
{id: 2, name: “Phone 7”, …},
…
]
であり、レスポンスがリストである。この場合、図１９（ａ）に示すＡＰＩのリソース名が“product”(単数) ではなく“products”(複数)となっているのは規約に沿っていると判断できる。

一方、図１９（ｃ）（ｄ）に示す例では、レスポンス“profile”はリストではなく、単一のオブジェクトであるため、リソース名が“profile”(単数)となっていることは規約に沿っている。
ＡＰＩのパラメータ名とその型の例は以下のようなものである。
profile: {
“name”: “aaaaa”,
“company”: “bbbbb”,
“interests”: [
{ “name”: “music”},
{ “name”: “programming”}
]
}
この、“interests”は配列となっているので、“interest”ではなくて“interests”であるのは正しい、という例である。
以上述べたＡＰＩ名とリソース名、パラメータ名の関係、およびレスポンスの型とリソース名の関係をトータルでチェックできる必要がある。

（実施形態）
図１は、本発明の実施形態に係るＡＰＩ規約チェック装置を示す構成図である。
ＡＰＩ規約チェック装置１００は、設計したＡＰＩが規約に沿っているかをチェックする。
図１に示すように、ＡＰＩ規約チェック装置１００は、ＡＰＩ仕様書アダプタ部１１０（ＡＰＩ仕様書アダプタ手段）と、ルールファイル格納部１２０（ルールファイル格納手段）と、チェック実行部１３０（チェック実行手段）と、チェック結果格納部１４０と、結果出力部１５０と、を備える。

［ＡＰＩ仕様書アダプタ部１１０］
ＡＰＩ仕様書アダプタ部１１０は、ＡＰＩ仕様書１の入力を受け付け、チェック実行部１３０から要求される項目としてＡＰＩ名、リソース名等を取得する。ＡＰＩ仕様書アダプタ部１１０は、それらの取得したＡＰＩ名、リソース名等をメモリ上などに保持する。本実施形態では、swagger specification形式（以下、swagger spec形式という）で書かれたＡＰＩ仕様書用のアダプタを例として挙げるが、別のアダプタを用意すれば他の形式にも対応可能である。
上記swagger spec形式は、ＡＰＩ仕様書のマシンリーダブルな記法（ＹＡＭＬ：YAML Ain't Markup Language)であり、ＹＡＭＬ（YAML Ain't Markup Language）等の形式で記述される。swaggerは、Open API Initiativeで標準化を目指している。

［ルールファイル格納部１２０］
ルールファイル格納部１２０は、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納する。
ルールファイル格納部１２０は、チェック対象定義ルールファイル１２１と、類義語定義ルールファイル１２２と、ＵＲＩ構成定義ルールファイル１２３と、ＡＰＩ名定義ルールファイル１２４と、リソース定義ルールファイル１２５と、スキーマ定義ルールファイル１２６と、を備える。
ここで、上記ルールファイルは、ＡＰＩ統制者によって予めインプットされる。
また、ルールファイル格納部１２０におけるルールファイルの記述形式は任意だが、swagger等の標準ＡＰＩ仕様書のフォーマットに合わせることが好ましい。

チェック対象定義ルールファイル１２１は、チェック対象となる項目を指定する。

類義語定義ルールファイル１２２は、ＡＰＩ名、リソース名、パラメータ名に用いる類義語を定義する。

ＵＲＩ構成定義ルールファイル１２３は、ホスト名、ＡＰＩ名、バージョン名の順番および有無を定義する。

ＡＰＩ名定義ルールファイル１２４は、ＡＰＩ名の候補／命名ルール、並びにＡＰＩ名で扱うリソース名を定義する。

リソース定義ルールファイル１２５は、リソース名の候補および、リソース名のリソースに関する操作一覧とインプット、アウトプットとを規定する。リソース定義ルールファイル１２５は、swaggerと同形式で規定する。

スキーマ定義ルールファイル１２６は、リソース定義に用いる、データスキーマの詳細を規定（パラメータ名を含む）する。スキーマ定義ルールファイル１２６は、swaggerと同形式で規定する。

［チェック実行部１３０］
チェック実行部１３０は、ルールファイル格納部１２０に格納されたルールファイルを参照して、要求項目に対してＡＰＩ規定に沿わない可能性がある箇所（ＡＰＩ規定に合わない箇所）をチェックする。
チェック実行部１３０は、レスポンスの型とリソース名の関係、および前記レスポンスの型とリソース名が単数形または複数形であることのチェックを行う。
チェック実行部１３０は、ＡＰＩ規約としてＵＲＩの階層の数を制限する場合、当該制限により影響があるリソースの構造と前記パラメータ名のチェックを行う。

チェック実行部１３０は、ＵＲＩ構成チェック部１３１と、ＡＰＩ名チェック部１３２と、リソース名チェック部１３３と、パラメータ名チェック部１３４と、ＡＰＩ名−リソース名対応チェック部１３５と、リソース名−パラメータ名対応チェック部１３６と、リソース階層数チェック部１３７と、を備える。

ＵＲＩ構成チェック部１３１は、ＵＲＩ構成のチェックをする（チェックの具体的内容は後記）。

ＡＰＩ名チェック部１３２は、ＡＰＩ名のチェックをする（チェックの具体的内容は後記）。

リソース名チェック部１３３は、リソース名のチェックをする（チェックの具体的内容は後記）。また、リソース名チェック部１３３は、リソース名の単数形／複数形規約をチェックし（チェックの具体的内容は後記）、ルールファイル自体をチェック対象とすることができる。

パラメータ名チェック部１３４は、パラメータ名のチェックをする。

ＡＰＩ名−リソース名対応チェック部１３５は、ＡＰＩ名とリソース名の対応チェックをする。

リソース名−パラメータ名対応チェック部１３６は、リソース名とパラメータ名の対応チェックをする。

リソース階層数チェック部１３７は、リソース階層の数をチェックする。リソース階層数チェック部１３７は、ルールファイル自体をチェック対象とすることができる。リソース階層数チェック部１３７は、リソース階層の数を変更したルールファイル／ＡＰＩ仕様書記述をチェック結果格納部１４０に登録する（詳細は後記）。

［チェック結果格納部１４０］
チェック結果格納部１４０は、チェック結果として、(1)警告と(2)注意とに分けて該当箇所と内容を登録する。

［結果出力部１５０］
結果出力部１５０は、チェック結果格納部１４０によるチェック結果を元に、設計者に対してアウトプットを行う。アウトプット形式は、リアルタイムなエディタ上への補完やポップアップを例として挙げるが、別の出力部を用意すればログファイルへの出力等も可能である。

以下、上述のように構成されたＡＰＩ規約チェック装置１００のＡＰＩ規約チェック方法について説明する。

［チェック対象定義］
まず、チェック対象定義について説明する。
図２は、各機能部によって参照されるチェック対象定義ルールファイル１２１の一例を示す図である。チェック対象定義ルールファイル１２１は、チェック対象となる項目を指定するものである。
図２に示すように、このチェック対象定義ルールファイル１２１には、
checkTargets:
- URI
- apiIName
- resourceName:
singularPluralPolicy: “pluralIfArray”
- parameterName:
singularPluralPolicy: “pluralIfArray”
- apiName-resourceName
- resourceName-parameterName
- maxHierarchy: 2
が定義されている。
なお、上記記述方法は一例であり、同様の内容が記述されていれば、この記法に限定するものではない。

このチェック対象定義ルールファイル１２１では、チェックターゲットとして、ＵＲＩ構成チェック部１３１「URI」と、ＡＰＩ名チェック部１３２「apiName」と、リソース名チェック部１３３「resourceName」と、パラメータ名チェック部１３４「parameterName」と、ＡＰＩ名−リソース名対応チェック部１３５「apiName-resourceName」と、リソース名−パラメータ名対応チェック部１３６「resourceName-parameterName」と、リソース階層数チェック部１３７「maxHierarchy」と、を参照することが定義されている。

図３は、チェック対象定義ルールファイル１２１を参照した各機能部が実行する処理を示す図である。
各機能部において、チェック対象定義ルールファイル１２１（図２参照）を参照し、チェック対象となっていた場合、それぞれの処理を実行する。

ＵＲＩ構成チェック部１３１は、チェック対象定義ルールファイル１２１で項目「URI」が指定されている。この場合、ＵＲＩ構成チェック部１３１は、ＵＲＩ構成のチェックをする。

ＡＰＩ名チェック部１３２は、チェック対象定義ルールファイル１２１で項目「apiName」が指定されている。この場合、ＡＰＩ名チェック部１３２は、ＡＰＩ名のチェックをする。

リソース名チェック部１３３は、チェック対象定義ルールファイル１２１で項目「resourceName」が指定されている場合、リソース名チェック部１３３は、リソース名のチェックをする。項目「resourceName」が指定されていない（記述されていない）場合、チェックをしない。「resourceName」が記述されている場合で、さらに「singularPluralPolicy」が指定されている場合には、リソース名の単数形／複数形規約をチェックする。具体的には、singular: すべて単数形、plural: すべて複数形、pluralIfArray: リストの場合は複数形、がある。

パラメータ名チェック部１３４は、チェック対象定義ルールファイル１２１で項目「parameterName」が指定されている場合、パラメータ名のチェックをする。項目「parameterName」が指定されていない（記述されていない）場合、チェックをしない。「parameterName」が記述されている場合で、さらにまた、singularPluralPolicyが指定されている場合には、パラメータ名の単数形／複数形規約をチェックする。具体的には、singular: すべて単数形、plural: すべて複数形、pluralIfArray: リストの場合は複数形、がある。

ＡＰＩ名−リソース名対応チェック部１３５は、チェック対象定義ルールファイル１２１で項目「apiName-resourceName」が指定されている場合、ＡＰＩ名とリソース名の対応チェックをする。

リソース名−パラメータ名対応チェック部１３６は、チェック対象定義ルールファイル１２１で項目「resourceName-parameterName」が指定されている場合、リソース名とパラメータ名の対応チェックをする。

リソース階層数チェック部１３７は、チェック対象定義ルールファイル１２１で項目「maxHierarchy」が指定されている場合、リソース階層の数（リソース階層の最大値）をチェックする。「maxHierarchy」が指定されていない(記述されていない)場合は、チェックを行わない。また、“maxHierarchy”だけ記述されており、その後に数字が書いていない場合は、単に文法エラーとし、定義ファイルの書き方の規則として、maxHierarchyを書くときは、必ず値となる数字を書く、ということにしておく。

［ＡＰＩ仕様書アダプタ部の動きの説明］
ＡＰＩ仕様書アダプタ部１１０の動きについて説明する。
swagger用のＡＰＩ仕様書アダプタ部１１０の場合、以下のようなロジックがアダプタに記述されている。
「ホスト名」「ＡＰＩ名」「バージョン名」「リソース名の前までのＵＲＬ」「リソース名」「階層数」「メソッド名」「(リクエスト／レスポンス)パラメータ名」「リストフラグ」が結果として取得され、これらは他の機能部から読み出せる。そのため、ＡＰＩ仕様書アダプタ部１１０は、他の機能部より先に実行されている必要がある。

１．“host”の値を「ホスト名」とする。
２．basePathの値を抽出する。“/”で区切られている場合、要素ごとに抽出する（後記図５における“articleManagement”と”v1”参照）。
３．v+数字、もしくは数字だけの要素があれば、それを「バージョン名」とする。それ以外を「ＡＰＩ名」とする(“articleManagement”)。もしそれ以外が存在しない場合、ホスト名の最初のドットの前(“api”)を「ＡＰＩ名」とする。
４．ＵＲＬチェック等に使用するため、「リソース名の前までのＵＲＬ」を生成する。具体的には、hostの値、basePathの値をつなげる。

５．pathsの要素を読み出し、最後の“/”の後を「リソース名」とする。
６．上記５．において、“/”の数から、各リソースが何階層目にあるか(「階層数」)を判別する。後記図１３（ａ）の場合、usersに対しては“/”が１つなので１階層目、articlesに対しては“/”が3個なので、２階層目というように、
階層の数＝[n/2]+1 (n: “/”の数, []はガウス記号であり、切り捨てを意味する)とする。
７．リソース名直下にある要素を「メソッド名」として抽出（“get”等）する。
８．“parameters”配下の”name”を「リクエストパラメータ名」として抽出する。
９．responses.schema.typeを参照し、”array”であればレスポンスがリストであると判断し、当該リソースの「リストフラグ」をtrueにする。
１０．responses.schema.items.propertiesを参照し、「レスポンスパラメータ名」として抽出(他所の参照”$ref:”が指定してある場合、そちらも参照)する。
１１．各パラメータに対し、typeが”array”であれば、「リストフラグ」をtrueとする。

［ＵＲＩ構成のチェック］
次に、図４および図５を参照してＵＲＩ構成のチェックについて説明する。
図４は、ＵＲＩ構成チェック部１３１におけるＵＲＩ構成のチェックの概要を示す図である。
図４に示すように、ＡＰＩ仕様書アダプタ部１１０（図１参照）は、ＡＰＩ仕様書１を有するサーバとの間でＵＲＩパスを生成し、ＡＰＩ仕様書１を読み込み、ＡＰＩ名、リソース名等、ＵＲＩ構成チェック部１３１から要求される項目を取得する。
ＵＲＩ構成チェック部１３１は、チェック対象定義ルールファイル１２１とＵＲＩ構成定義ルールファイル１２３とを参照してＵＲＩ構成のチェックを行い、結果出力部１５０に出力する。

図５は、ＵＲＩ構成チェック部１３１におけるＵＲＩ構成のチェックの詳細を説明する図であり、図５（ａ）は、ＡＰＩ仕様書１の一例を示す図、図５（ｂ）は、ルールファイル格納部１２０（図１参照）のＵＲＩ構成定義ルールファイル１２３のうち、「（Ａ）ＡＰＩ名はホスト名の後」である場合の一例と、「（Ｂ）ＡＰＩ名はホスト名の前」である場合の一例とを示す。

図５（ａ）に示すＡＰＩ仕様書１は、
host: api.sample.com
basePath: /articleManagement/v1
paths:
/users:
/articles:
であり、ＡＰＩ名は、
articleManagement
である。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）から、「リソース名の前までのＵＲＩ」が生成されていることを前提とする。図５（ａ）の例の場合、「api.sample.com/articleManagement/v1」となる。

ＵＲＩ構成チェック部１３１（図１参照）は、図５（ｂ）に示すチェック対象定義ルールファイル１２１とＵＲＩ構成定義ルールファイル１２３とを参照してＵＲＩ構成のチェックを行う。
ＵＲＩ構成チェック部１３１は、ＡＰＩ仕様書アダプタ部１１０（図１参照）よりホスト名、ＡＰＩ名、バージョン名をそれぞれ取得する。それらとＵＲＩ構成定義ルールファイル１２３の記載を基に、ＵＲＩ（(1)）を作成する。同様に、ＡＰＩ仕様書アダプタ部１１０（図１参照）よりリソース名の前までのＵＲＬ（(2)）を取得する。ＵＲＬ(1)とＵＲＬ(2)を比較し、一致していたら規約に沿っているため何もせず、不一致であれば警告“ＵＲＩの構成が規約に沿っていません”を結果としてチェック結果格納部１４０に登録する。例えば、（Ａ）の場合、ＵＲＬ(1)は“api.sample.com/articleManagement/v1”となりＵＲＬ(2)と等しいため、規約に沿っている。一方、（Ｂ）の場合、ＵＲＬ(1)は“articleManagement.api.sample.com/v1”となり、ＵＲＬ(2)と不一致のため、規約違反となる。

［ＡＰＩ名のチェック］
次に、図６を参照してＡＰＩ名のチェックについて説明する。
図６は、ＡＰＩ名チェック部１３２のＡＰＩ名チェックの詳細を説明する図であり、図６（ａ）は、ＡＰＩ仕様書１の一例を示す図、図６（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのうち、ＡＰＩ名定義ルールファイル１２４と類義語定義ルールファイル１２２の一例を示す図である。

図６（ａ）に示すＡＰＩ仕様書１は、
host: api.sample.com
basePath: / customerManagement/v1
paths:
/users:
/articles:
であり、ＡＰＩ名は、
customerManagement
である。なお、上述した図５のＡＰＩ仕様書１とＡＰＩ名が異なっている。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）から、ＡＰＩ名が取得されていることを前提とする。図６（ａ）の例では、customerManagementがＡＰＩ名となる。

ＡＰＩ名チェック部１３２のＡＰＩ名チェックのうち、ＡＰＩ名定義ルールファイル１２４を用いたＡＰＩ名チェックの具体例は、下記である。
図６（ｂ）のＡＰＩ名定義ルールファイル１２４は、
apiName:
names:
- userManagement:
description: ユーザ管理ＡＰＩ
resources:
- users
- articleManagement
description: 記事管理ＡＰＩ
resources:
- articles
- /*Management/
style: camelCase
である。

ＡＰＩ名チェック部１３２（図１参照）は、図６（ｂ）に示すＡＰＩ名定義ルールファイル１２４を参照し、抽出したＡＰＩ名が候補に該当するかチェックする。該当するものがなければ、警告 ”ＡＰＩ名がルールに従っていません”としてチェック結果格納部１４０に登録する。図６（ｂ）の符号ａに示すＡＰＩ名の候補は「userManagement」と、図６（ｂ）の符号ｂに示す「articleManagement」と、図６（ｂ）の符号ｃに示す「*Management」とがある。上記リソース名のＡＰＩ名の候補の抽出において、正規表現の使用も可とし、例えば図６（ｂ）の符号ｃでは「*」（ワイルドカード）による部分一致定義を行っている。

また、ＡＰＩ名チェック部１３２は、ＡＰＩ名定義ルールファイル１２４のstyleを参照し、抽出したＡＰＩ名が表記規約に沿っているかをチェックする。抽出したＡＰＩ名が表記規約に沿っていなければ警告“ＡＰＩ名の表記規約がルールに従っていません”としてチェック結果格納部１４０に登録する。

図６（ｂ）に示すように、類義語定義ルールファイル１２２には、
user:
candidates:
- name: customer
recommended: true
- name: client
recommended: true
が定義されている。

ＡＰＩ名チェック部１３２は、図６（ｂ）に示す類義語定義ルールファイル１２２を参照し、抽出したＡＰＩ名に該当単語が含まれていた場合、他の単語候補と共に注意事項としてチェック結果格納部１４０に登録する。ただし、recommendedがtrueのもののみとする。また、該当単語を候補単語に変換した結果、ＡＰＩ名の候補に完全一致するものがあれば、その候補単語のみ登録する。
図６（ｂ）の符号ｅに示すように、該当単語は「user」、図６（ｂ）の符号ｆに示すように、候補単語は「customer」である。該当単語「user」と候補単語「customer」とは、類似している単語である。
ＡＰＩ名チェック部１３２は、図６（ｂ）の符号ｇに示すように、レコメンドに含めるかどうかをチェックする。例えば、学習機能により、”userはすべてcustomerに変換する”とした場合、他の候補単語(client等)のrecommendedはfalseにする。

［リソース名のチェック］
次に、図７を参照してリソース名のチェックについて説明する。
図７は、リソース名チェック部１３３のリソース名チェックの詳細を説明する図であり、図７（ａ）は、ＡＰＩ仕様書１の一例を示す図、図７（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのうち、リソース定義ルールファイル１２５と類義語定義ルールファイル１２２の一例を示す図である。

図７（ａ）に示すＡＰＩ仕様書１は、
host: api.sample.com
basePath: /userManagement/v1
paths:
/users:
/articles:
であり、ＡＰＩ名は、
userManagement
である。なお、上述した図５および図６のＡＰＩ仕様書１とＡＰＩ名が異なっている。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）から、リソース名が抽出されていることを前提とする。

リソース名チェック部１３３（図１参照）は、リソース定義ルールファイル１２５のpathsを取得し、リソース名の候補に該当するものがあるかチェックする。リソース名の候補に該当するものがなければ、警告“リソース名が規約に沿っていません”としてチェック結果格納部１４０に登録する。図７（ｂ）の符号ｈに示すリソース名の候補「users」と、図７（ｂ）の符号ｉに示すリソース名の候補「articles」とがチェックされている。

図７（ｂ）に示すように、類義語定義ルールファイル１２２には、
user:
candidates:
- name: customer
recommended: true
- name: client
recommended: true
が定義されている。

ＡＰＩ名チェック部１３２は、図７（ｂ）に示す類義語定義ルールファイル１２２を参照し、抽出したリソース名に該当単語が含まれていた場合、他の単語候補と共に注意事項としてチェック結果格納部１４０に登録する。ただし、recommendedがtrueのもののみとする。また、該当単語を候補単語に変換した結果、リソース名の候補に完全一致するものがあれば、その候補単語のみ登録する。

［リソース名の単数形／複数形規約チェック］
次に、図８を参照してリソース名の単数形／複数形規約チェックについて説明する。
図８は、リソース名チェック部１３３のリソース名チェックの詳細を説明する図であり、図８（ａ）は、ＡＰＩ仕様書１の一例を示す図、図８（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのチェック対象定義ルールファイル１２１の一例を示す図である。

図８（ａ）に示すＡＰＩ仕様書１からリソース名が抽出されていることを前提とする。
図８（ａ）に示すＡＰＩ仕様書１は、
paths:
/users:
get:
parameters:
- name: id
in: query
required: true
type: number
format: string
responses:
200:
description: ユーザのリスト
schema:
type: array
items:
$ref: ‘#/definitions/User’
である。

図８（ｂ）に示すチェック対象定義ルールファイル１２１は、
checkTargets:
- URI
- apiName
- resourceName:
singularPluralPolicy: “pluralIfArray”
- parameterName:
singularPluralPolicy: “pluralIfArray”
- apiName-resourceName
- resourceName-parameterName
- maxHierarchy: 2
を定義する。

リソース名チェック部１３３（図１参照）は、図８（ｂ）に示すチェック対象定義ルールファイル１２１を参照し、resourceName: singularPluralPolicy = “singular”が設定されている場合、抽出したリソース名が単数形でないとき、警告をチェック結果格納部１４０に格納する。この警告は、例えば“リソース名が単数形／複数形規約に沿っていません”である。また、resourceName: singularPluralPolicy = “plural”が設定されている場合、抽出したリソース名が複数形でないとき、警告する。この警告は、例えば“リソース名が単数形／複数形規約に沿っていません”である。

また、resourceName: singularPluralPolicy = “pluralIfArray”が設定されている場合は、下記（１）（２）である。
（１）ＡＰＩ仕様書アダプタ部１１０（図１参照）により、図８（ａ）に示すＡＰＩ仕様書１からリソースのレスポンスがリストかそうでないかが取得されていることを前提とする。リソース名チェック部１３３（図１参照）はＡＰＩ仕様書アダプタ部１１０（図１参照）より、対象リソースの「リストフラグ」を取得する。
（２）上記（１）においてリストフラグがtrueの場合、リソース名が複数形でなければ警告し、リストフラグがfalseの場合、リソース名が単数形でなければ警告する。
なお、本リソース名の単数形／複数形規約チェック機能は、ルールファイルのうち、リソース定義ルールファイル１２５に対しても適用することができる。

［ＡＰＩ名とリソース名の対応チェック］
次に、図９を参照してＡＰＩ名とリソース名の対応チェックについて説明する。
図９は、リソース名チェック部１３３のリソース名チェックの詳細を説明する図であり、図９（ａ）は、ＡＰＩ仕様書１の一例を示す図、図９（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのうち、リソース定義ルールファイル１２５と類義語定義ルールファイル１２２の一例を示す図である。

図９（ａ）に示すＡＰＩ仕様書１からＡＰＩ名とリソース名が抽出されていることを前提とする。例えば、図９（ａ）では、ＡＰＩ名はcustomerManagementであり、対応するリソース名はusersおよびarticlesである。
図９（ａ）に示すＡＰＩ仕様書１は、
host: api.sample.com
basePath: /customerManagement/v1
paths:
/users:
/articles:
である。
なお、上述した図５、図６および図７のＡＰＩ仕様書１とＡＰＩ名が異なっている。

図９（ｂ）に示すＡＰＩ名定義ルールファイル１２４は、
apiName:
names:
- userManagement:
description: ユーザ管理ＡＰＩ
resources:
- User
- articleManagement
description: 記事管理ＡＰＩ
resources: Article
- /*Management/
style: camelCase
を定義する。

ＡＰＩ名−リソース名対応チェック部１３５は、図９（ｂ）に示すＡＰＩ名定義ルールファイル１２４を参照して抽出したリソース名がＡＰＩ名の候補に該当するかチェックする。ここでは、ＡＰＩ名−リソース名対応チェック部１３５は、ＡＰＩ名定義ルールファイル１２４のapiName.names.{ＡＰＩ名}.resourcesを参照し、抽出したリソース名がＡＰＩ名の候補に該当するかチェックする。該当するものがなければ、警告”ＡＰＩ名とリソース名の対応がルールに従っていません”として登録する。なお、上記リソース名がＡＰＩ名の候補の抽出では、後記図９（ｂ）に示す類義語定義ルールファイル１２２を参照して、ＡＰＩ名の候補に類義語定義されたＡＰＩ名の候補を含めるようにする。

図９（ｂ）の例では、
図９（ｂ）の符号ｊに示すＡＰＩ名の候補
- userManagement:
description: ユーザ管理ＡＰＩ
resources:
と、図９（ｂ）の符号ｋに示すＡＰＩ名の候補
- articleManagement
description: 記事管理ＡＰＩ
resources: Article
を抽出する。
図９（ｂ）の符号ｌに示すように、上記リソース名のＡＰＩ名の候補の抽出において、正規表現による部分一致定義も可とする。

図９（ｂ）に示すように、類義語定義ルールファイル１２２には、
user:
candidates:
- name: customer
recommended: true
- name: client
recommended: true
が定義されている。

また、ＡＰＩ名−リソース名対応チェック部１３５は、図９（ｂ）に示す類義語定義ルールファイル１２２を参照して、抽出したリソース名に該当単語が含まれていた場合、他の単語候補と共に注意事項として登録する。ただし、recommendedがtrueのもののみとする。また、該当ＡＰＩ名の候補を候補単語に変換した結果、リソース名がＡＰＩ名の候補に完全一致するものがあれば、その候補単語のみ登録する。

［パラメータ名のチェックの対応チェック］
次に、図１０を参照してパラメータ名のチェックについて説明する。
図１０は、パラメータ名チェック部１３４のパラメータ名のチェックの詳細を説明する図であり、図１０（ａ）は、ＡＰＩ仕様書１の一例を示す図、図１０（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのうち、リソース定義ルールファイル１２５と類義語定義ルールファイル１２２とスキーマ定義ルールファイル１２６との一例を示す図である。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）からパラメータ名が抽出されていることを前提とする。
図１０（ａ）に示すＡＰＩ仕様書１は、ＡＰＩ仕様書１（１ａ）とＡＰＩ仕様書１（１ｂ）である。

図１０（ａ）に示すＡＰＩ仕様書１において、パラメータ名（リクエスト／レスポンスのパラメータ名）は、
ＡＰＩ仕様書１（１ａ）では、
id
であり、
ＡＰＩ仕様書１（１ｂ）では、
idとname
である。

パラメータ名チェック部１３４（図１参照）は、図１０（ｂ）に示すリソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６を参照し、抽出したパラメータ名がパラメータ名の候補に該当するか否かをチェックする。抽出したパラメータ名がパラメータ名の候補に該当しない場合、警告“パラメータ名が規約に沿っていません”としてチェック結果格納部１４０に登録する。

図１０（ｂ）の例では、リソース定義ルールファイル１２５から、図１０（ｂ）の符号ｍに示すパラメータ名の候補「id」を抽出する。このidは、インプットパラメータである。
また、スキーマ定義ルールファイル１２６から、図１０（ｂ）の符号ｏに示すパラメータ名の候補「id」と図１０（ｂ）の符号ｎに示す「name」を抽出する。

パラメータ名チェック部１３４（図１参照）は、図１０（ｂ）に示す類義語定義ルールファイル１２２を参照し、抽出したパラメータ名に該当単語が含まれていた場合、他の単語候補と共に注意事項としてチェック結果格納部１４０に登録する。ただし、この注意事項の登録は、recommendedがtrueのもののみとする。また、該当単語を候補単語に変換した結果、パラメータ名の候補に完全一致するものがあれば、その候補単語のみ登録する。

［パラメータ名の単数形／複数形規約チェック］
次に、図１１を参照してパラメータ名の単数形／複数形規約チェックについて説明する。
図１１は、パラメータ名チェック部１３４の単数形／複数形規約チェックの詳細を説明する図であり、図１１（ａ）は、ＡＰＩ仕様書１の一例を示す図、図１１（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのうち、チェック対象定義ルールファイル１２１の一例を示す図である。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）からパラメータ名が抽出されていることを前提とする。

図１１（ａ）に示すＡＰＩ仕様書１は、ＡＰＩ仕様書１（１ａ）とＡＰＩ仕様書１（１ｂ）である。
図１１（ａ）に示すＡＰＩ仕様書１において、パラメータ名（リクエスト／レスポンスのパラメータ名）は、
ＡＰＩ仕様書１（１ａ）では、パラメータ名
id
であり、
ＡＰＩ仕様書１（１ｂ）では、パラメータ名
idとname
である。

パラメータ名チェック部１３４（図１参照）は、図１１（ｂ）に示すチェック対象定義ルールファイル１２１を参照し、抽出したパラメータ名の単数形／複数形規約チェックを行う。この例では、図１１（ｂ）に示すチェック対象定義ルールファイル１２１に、
- parameterName:
singularPluralPolicy: “pluralIfArray”
が設定されている。パラメータ名チェック部１３４は、パラメータ名が単数形／複数形規約に沿っているか下記の判定を行う。

図１１（ｂ）に示すチェック対象定義ルールファイル１２１に、parameterName: singularPluralPolicy = “singular”が設定されている場合、抽出したリソース名が複数形でない場合、“パラメータ名が単数形／複数形規約に沿っていません”を警告する。

図１１（ｂ）に示すチェック対象定義ルールファイル１２１に、parameterName: singularPluralPolicy = “plural”が設定されている場合、抽出したリソース名が複数形でない場合、“パラメータ名が単数形／複数形規約に沿っていません”を警告する。

図１１（ｂ）に示すチェック対象定義ルールファイル１２１に、parameterName: singularPluralPolicy = “pluralIfArray”が設定されている場合、下記（１）（２）である。
（１）ＡＰＩ仕様書アダプタ部１１０（図１参照）より、パラメータがリストかそうでないかを取得するため、対象パラメータの「リストフラグ」値を取得する。
（２）上記フラグがtrueの場合は、パラメータ名が複数形でなければ警告し、falseの場合は、パラメータ名が単数形でなければ警告する。
なお、本パラメータ名の単数形／複数形規約チェック機能は、リソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６に対しても適用することができる。

［リソース名とパラメータ名の対応チェック］
次に、図１２を参照してリソース名とパラメータ名の対応チェックについて説明する。
図１２は、リソース名−パラメータ名対応チェック部１３６のリソース名とパラメータ名の対応チェックの詳細を説明する図であり、図１２（ａ）は、ＡＰＩ仕様書１の一例を示す図、図１２（ｂ）は、リソース名−パラメータ名対応チェック部１３６（図１参照）のルールファイルのうち、リソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６の一例を示す図である。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）からリソース名が抽出されていることを前提とする。
図１２（ａ）に示すＡＰＩ仕様書１は、ＡＰＩ仕様書１（１ａ）とＡＰＩ仕様書１（１ｂ）である。

図１２（ａ）に示すＡＰＩ仕様書１において、リソース名は、usersであり、パラメータ名（リクエスト／レスポンスのパラメータ名）は、
ＡＰＩ仕様書１（１ａ）では、
id
であり、
ＡＰＩ仕様書１（１ｂ）では、
idとname
である。

図１２（ｂ）の例では、
リソース定義ルールファイル１２５から、図１２（ｂ）の符号ｐに示すパラメータ名の候補「id」を抽出する。
また、スキーマ定義ルールファイル１２６から、図１２（ｂ）の符号ｒに示すパラメータ名の候補「id」と図１２（ｂ）の符号ｑに示す「name」を抽出する。

リソース名−パラメータ名対応チェック部１３６は、リソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６を参照し、抽出したパラメータ名がパラメータ名の候補に該当するかチェックする。抽出したパラメータ名がパラメータ名の候補に該当しない場合、警告“リソース名とパラメータ名の対応が規約に沿っていません” としてチェック結果格納部１４０に登録する。

［リソース名の階層数チェック］
次に、図１３を参照してリソース名の階層数チェックについて説明する。
図１３は、リソース階層数チェック部１３７におけるリソース名の階層数チェックの詳細を説明する図であり、図１３（ａ）は、ＡＰＩ仕様書１の一例を示す図、図１３（ｂ）は、ルールファイル格納部１２０（図１参照）のルールファイルのチェック対象定義ルールファイル１２１の一例を示す図である。

ＡＰＩ仕様書アダプタ部１１０（図１参照）により、ＡＰＩ仕様書１（図１参照）からリソース名が抽出されていることを前提とする。

図１３（ａ）に示すＡＰＩ仕様書１において、リソース名は、
users
および
articles
である。

リソース階層数チェック部１３７（図１参照）は、図１３（ｂ）に示すチェック対象定義ルールファイル１２１を参照して、図１３（ａ）に示すＡＰＩ仕様書１から、規定以上の階層になっている箇所を見つける。具体的には、ＡＰＩ仕様書アダプタ部１１０（図１参照）より、各リソースに対する「階層数」を取得し、これが図１３（ｂ）に示すチェック対象定義ルールファイル１２１で定義される、規約としての階層の数より多かったら規約違反とする。例えば、図１３（ｂ）に示すチェック対象定義ルールファイル１２１では、maxHierarchy: 1（リソース階層数:１）が定義されている。しかしながら、上記図１３（ａ）の符号ｓの記述では、/users/{id}/articlesとなっており、「articles」は２階層目に存在するため、規約違反となる。このようにして、リソース階層数チェック部１３７は、リソース階層数が規定以上の階層になっている箇所を見つけることができる。

リソース階層数チェック部１３７は、図１３（ｂ）に示すチェック対象定義ルールファイル１２１を参照し、チェック対象定義ルールファイル１２１に、maxHierarchyが設定されている場合、以下の処理を実行する。
（１）リソース階層数チェック部１３７は、ＡＰＩ仕様書アダプタ部１１０（図１参照）より取得した階層の数がmaxHierarchyの値より大きい場合、“階層の数が規約に反しています”を警告する。
なお、本リソース名の階層数チェック機能は、ルールファイルのうち、リソース定義ルールファイル１２５に対しても適用することができる。

［階層数変更提案］
上述したように、上記図１３（ａ）に示すリソース定義ルールファイル１２５および図１３（ｂ）に示すスキーマ定義ルールファイル１２６には、リソース名に階層の数ポリシーに反する部分が含まれている。
そこで上述したリソース名の階層数チェック（図１３参照）において、リソース階層数チェック部１３７（図１参照）が、リソース名に階層の数ポリシーに反する部分を検出した場合、下記の手順で低階層化の提案を行うことができる。また、高階層化は、これとは逆の手順となる。
低階層化または高階層化の提案対象は、ＡＰＩ仕様書とリソース定義ルールファイル１２５との両方に対して適用可能である。

図１４および図１５を参照して階層数変更提案について説明する。
図１４は、リソース階層数チェック部１３７の階層数変更提案の詳細を説明する図である。図１４（ａ）は、リソース名に階層の数ポリシーに反する部分を有するリソース定義ルールファイル１２５を示す図であり、図１４（ｂ）は、リソース名に階層の数ポリシーに反する部分を有するスキーマ定義ルールファイル１２６を示す図である。

図１４（ｂ）に示すスキーマ定義ルールファイル１２６は、
definitions:
User:
type: object
properties:
id:
type: string
description: ユーザを識別するためのID
name:
type: string
description: ユーザ名
Article:
type: object
properties:
id:
type: string
description: 記事ID
title:
type: string
description: 記事のタイトル
を定義する。

リソース階層数チェック部１３７（図１参照）は、前述の手順で規定以上の階層になっている箇所を見つける。
リソース階層数チェック部１３７は、下記の手順で低階層化の提案を行う。
なお、以下の手順では、リソース階層数チェック部１３７がＡＰＩ仕様書アダプタ部１１０（図１参照）に指示を出し、実際にＡＰＩ仕様書を記述するのはＡＰＩ仕様書アダプタ部１１０（図１参照）になる。

図１５は、図１４を低階層化する場合の、リソース階層数チェック部１３７の階層数変更提案の詳細を説明する図である。図１５（ａ）は、低階層化されたリソース定義ルールファイル１２５を示す図であり、図１５（ｂ）は、低階層化されたスキーマ定義ルールファイル１２６を示す図である。

図１５（ａ）に示す低階層化されたリソース定義ルールファイル１２５は、
paths:
/users:
get:
parameters:
- name: id
in: query
required: true
type: number
format: string
responses:
200:
description: ユーザのリスト
schema:
type: array
items:
$ref: ‘#/definitions/User’

/articles:
get:
parameters:
- name: id
in: query
required: true
type: number
format: string
- name: userId
in: query
required: true
type: number
format: string
responses:
200:
description: 記事のリスト
schema:
type: array
items:
$ref: ‘#/definitions/Article’
を定義する。

図１５（ｂ）に示す低階層化されたスキーマ定義ルールファイル１２６は、
definitions:
User:
type: object
properties:
id:
type: string
description: ユーザを識別するためのID
name:
type: string
description: ユーザ名
Article:
type: object
properties:
id:
type: string
description: 記事ID
title:
type: string
description: 記事のタイトル
userId:
type: string
(description: 記事に紐づくユーザID)
を定義する。

ＡＰＩ仕様書アダプタ部１１０（図１参照）は、図１５（ａ）の符号ｕに示すように、規定以上の階層になっている「/users/{id}/articles」（図１４（ａ）参照）のうち、最終階層「articles」だけを残す記述とする。そして、図１５（ａ）の符号ｖに示すように、リソース階層数変更前のリソース定義ルールファイル１２５から“{削除した階層(user)}Id” をリクエストパラメータに追加する。すなわち、図１５（ａ）の符号ｖに示すように、“{削除した階層(user)}Id”の、
- name: userId
in: query
required: true
type: number
format: string
をリクエストパラメータに追加する。

これに伴い、ＡＰＩ仕様書アダプタ部１１０（図１参照）は、図１５（ｂ）の符号ｗに示すように、上記“{削除した階層(user)}Id” を最終階層(article)のスキーマに追加する。すなわち、図１５（ｂ）の符号ｗに示すように、リソース階層数チェック部１３７は、スキーマ定義ルールファイル１２６の最終階層(article)のスキーマに、
userId:
type: string
を追加する。
以上により、図１４に示すリソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６は、低層化され、図１５に示す低層化されたリソース定義ルールファイル１２５およびスキーマ定義ルールファイル１２６が得られる。

以上説明したように、本実施形態のＡＰＩ規約チェック装置１００（図１参照）は、ＡＰＩ仕様書１およびＡＰＩ規約の入力を受け付け、ＡＰＩ仕様書１から所定の要求項目を取得するＡＰＩ仕様書アダプタ部１１０と、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納部１２０と、ルールファイルを参照して、要求項目に対してＡＰＩ規定に合わない箇所をチェックするチェック実行部１３０と、チェック実行部１３０によるチェック結果として、(1)警告と(2)注意とに分けて該当箇所と内容を登録するチェック結果格納部１４０と、チェック結果格納部１４０のチェック結果を元に、ＡＰＩ設計者に対してアウトプットを行う結果出力部１５０と、を備える。

本実施形態では、ルールファイル格納部１２０は、ルールファイルとして、チェック対象となる項目を指定するチェック対象定義ルールファイル１２１、ＡＰＩ名、リソース名、パラメータ名提案に用いる類義語を定義する類義語定義ルールファイル１２２、ホスト名、ＡＰＩ名、バージョン名の順番および有無を定義するＵＲＩ構成定義ルールファイル１２３、ＡＰＩ名の候補／命名ルール、および該当ＡＰＩ名で扱うリソース名を定義するＡＰＩ名定義ルールファイル１２４、リソース名の候補および、該当リソースに関する操作一覧とインプット、アウトプットを規定するリソース定義ルールファイル１２５、リソース定義に用いるデータスキーマ詳細を規定するスキーマ定義ルールファイル１２６のうち、少なくともいずれか１つを含む。

本実施形態では、前記チェック実行部１３０は、ＵＲＩ構成のチェックを行うＵＲＩ構成チェック部１３１、ＡＰＩ名のチェックを行うＡＰＩ名チェック部１３２、リソース名のチェックを行うとともに、リソース名の単数形／複数形規約をチェックするリソース名チェック部１３３、パラメータ名のチェックを行うパラメータ名チェック部１３４、ＡＰＩ名とリソース名の対応チェックを行うＡＰＩ名−リソース名対応チェック部１３５、リソース名とパラメータ名の対応チェックを行うリソース名−パラメータ名対応チェック部１３６、リソース階層の数をチェックするリソース階層数チェック部１３７のうち、少なくともいずれか１つを備える。

そして、ＡＰＩ規約チェック装置１００のＡＰＩ規約チェック方法では、ＡＰＩ仕様書１およびＡＰＩ規約を入力し、ＡＰＩ仕様書１から所定の要求項目を取得するステップと、ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するステップと、前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に沿わない可能性がある箇所をチェックするステップと、を実行する。

本実施形態のＡＰＩ規約チェック装置１００およびＡＰＩ規約チェック方法により、以下の作用効果を得ることができる。
図１において、ＡＰＩ統制者は、ルールファイル格納部１２０のルールファイルを予めインプットしておく。ルールファイル格納部１２０は、ルールファイルの定義を標準ＡＰＩ仕様書のフォーマットに合わせることが好ましい。
ＡＰＩ設計者がＡＰＩ仕様書１（例えば、swagger形式で記述されている）を入力すると、チェック実行部１３０（図１参照）は、ルールファイル格納部１２０のルールファイルを参照して、ＡＰＩ規定に沿わない可能性がある箇所をチェックする。チェック結果格納部１４０は、チェック結果を格納し、結果出力部１５０は、チェック結果を元に、ＡＰＩ設計者に対してアウトプットを行う。アウトプット形式は、例えばリアルタイムなエディタ上への補完やポップアップである。

これにより、ＡＰＩに特有のＵＲＬ、リソース名、パラメータ名の相互の関係（相互依存性）を加味することで、それらの組合せによるＡＰＩ規約の定義とチェックが可能になる。すなわち、ＡＰＩ仕様書およびＡＰＩ規約を入力として、設計したＡＰＩが規約に沿っているかをチェックできる。特に、単にＡＰＩ名・リソース名・パラメータ名等を辞書と比較するだけでなく、複数の項目に影響するルールの作成とチェックが可能になる。このため、ＡＰＩ設計者およびＡＰＩ統制者によるＡＰＩ規約のチェックが大幅に簡易化される。

また、”パラメータ名だけ”など、一部のみでなく、ＡＰＩ設計時に必要になる様々なレベル（ＵＲＩないしパラメータ名）の規約に対応することができる。

また、ＡＰＩに特有のＵＲＬ、リソース名、パラメータ名の相互依存性を理解することで、精度の高いＡＰＩ規約の定義とチェックが可能になる。

また、ＡＰＩ規約が変わった場合でも、上記ルールファイルを更新するだけで自動チェックが可能になる。

また、ＡＰＩ規約（またはルールファイル）自体のチェック機能により、ＡＰＩ規約作成者の作業も簡易化させることができる。

本実施形態では、ルールファイル格納部１２０は、ルールファイルの定義を標準ＡＰＩ仕様書のフォーマットに合わせることで、同じロジックを用いて、標準ＡＰＩ仕様書をもとにＡＰＩ規約を定義するルールファイル自体のチェックも可能となる。これにより、ルールファイルをインプットするＡＰＩ統制者の稼働を削減することができ、ＡＰＩ規約の精度向上につながる。
また、ＡＰＩ規約が変わった場合でも、上記ルールファイルを更新するだけで自動チェックが可能になる。また、一部の規約チェック機能はルールファイルに対しても適用できるため、ＡＰＩ規約作成自体もサポートが可能になる。

本実施形態では、チェック実行部１３０は、レスポンスの型とリソース名の関係、および前記レスポンスの型と前記リソース名が単数形または複数形であることのチェックを行うことで、表層の名前合わせだけでなく、レスポンスの型とリソース名の関係、単数形または複数形を相互の関係のルールとしてその記述をチェックでき、またバージョン管理することができる。その結果、ＡＰＩ設計の精度向上を図ることができる。

本実施形態では、チェック実行部１３０は、ＡＰＩ規約としてＵＲＩの階層の数を制限する場合、当該制限により影響があるリソースの構造と前記パラメータ名のチェックを行うことで、ＵＲＩの階層の数の制限で影響があるリソースの構造とパラメータ名についてものチェックを行うことができるとともに、リソース階層の数を変更した場合であってもリソースの構造とパラメータ名のチェックすることができる。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。

１００ ＡＰＩ規約チェック装置
１１０ ＡＰＩ仕様書アダプタ部（ＡＰＩ仕様書アダプタ手段）
１２０ ルールファイル格納部（ルールファイル格納手段）
１２１ チェック対象定義ルールファイル
１２２ 類義語定義ルールファイル
１２３ ＵＲＩ構成定義ルールファイル
１２４ ＡＰＩ名定義ルールファイル
１２５ リソース定義ルールファイル
１２６ スキーマ定義ルールファイル
１３０ チェック実行部（チェック実行手段）
１３１ ＵＲＩ構成チェック部
１３２ ＡＰＩ名チェック部
１３３ リソース名チェック部
１３４ パラメータ名チェック部
１３５ ＡＰＩ名−リソース名対応チェック部
１３６ リソース名−パラメータ名対応チェック部
１３７ リソース階層数チェック部

Claims (8)

1. 設計したＡＰＩ（Application Program Interface）がＡＰＩ規約に沿っているかをチェックするＡＰＩ規約チェック装置であって、
   ＡＰＩ仕様書および前記ＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するＡＰＩ仕様書アダプタ部と、
   ＡＰＩに特有のＵＲＬ（Uniform Resource Locator）、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納部と、
   前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するチェック実行部と、を備える
   ことを特徴とするＡＰＩ規約チェック装置。
2. 前記ルールファイル格納部は、前記ルールファイルとして、
   チェック対象となる項目を指定するチェック対象定義ルールファイル、
   ＡＰＩ名、リソース名、パラメータ名に用いる類義語を定義する類義語定義ルールファイル、
   ホスト名、ＡＰＩ名、バージョン名の順番および有無を定義するＵＲＩ（Uniform Resource Identifier）構成定義ルールファイル、
   ＡＰＩ名の候補および／または命名ルール、並びに前記ＡＰＩ名で扱うリソース名を定義するＡＰＩ名定義ルールファイル、
   リソース名の候補および、前記リソース名のリソースに関する操作一覧とインプット、アウトプットとを規定するリソース定義ルールファイル、
   リソース定義に用いるデータスキーマを規定するスキーマ定義ルールファイルのうち、少なくともいずれか１つを含む
   ことを特徴とする請求項１に記載のＡＰＩ規約チェック装置。
3. 前記ルールファイル格納部は、
   前記ルールファイルの定義を標準ＡＰＩ仕様書のフォーマットに合わせる
   ことを特徴とする請求項１または請求項２に記載のＡＰＩ規約チェック装置。
4. 前記チェック実行部は、
   レスポンスの型とリソース名の関係、および前記レスポンスの型と前記リソース名が、単数形または複数形であることのチェックを行う
   ことを特徴とする請求項１に記載のＡＰＩ規約チェック装置。
5. 前記チェック実行部は、
   前記ＡＰＩ規約としてＵＲＩの階層の数が制限される場合、当該制限により影響があるリソースの構造と前記パラメータ名のチェックを行う
   ことを特徴とする請求項１に記載のＡＰＩ規約チェック装置。
6. 前記チェック実行部は、
   ＵＲＩ構成のチェックを行うＵＲＩ構成チェック部、
   前記ＡＰＩ名のチェックを行うＡＰＩ名チェック部、
   前記リソース名のチェックを行うとともに、前記リソース名の単数形および／または複数形規約をチェックするリソース名チェック部、
   前記パラメータ名のチェックを行うパラメータ名チェック部、
   前記ＡＰＩ名と前記リソース名との対応チェックを行うＡＰＩ名−リソース名対応チェック部、
   前記リソース名と前記パラメータ名との対応チェックを行うリソース名−パラメータ名対応チェック部、
   リソース階層の数をチェックするリソース階層数チェック部のうち、少なくともいずれか１つを備える
   ことを特徴とする請求項１に記載のＡＰＩ規約チェック装置。
7. 設計したＡＰＩ（Application Program Interface）がＡＰＩ規約に沿っているかをチェックするＡＰＩ規約チェック装置が、
   ＡＰＩ仕様書および前記ＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するステップと、
   ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するステップと、
   前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するステップと、を実行する
   ことを特徴とするＡＰＩ規約チェック方法。
8. 設計したＡＰＩ（Application Program Interface）がＡＰＩ規約に沿っているかをチェックするＡＰＩ規約チェック装置としてのコンピュータを、
   ＡＰＩ仕様書および前記ＡＰＩ規約の入力を受け付け、前記ＡＰＩ仕様書から所定の要求項目を取得するＡＰＩ仕様書アダプタ手段、
   ＡＰＩに特有のＵＲＬ、ＡＰＩ名、当該ＡＰＩ名で扱うリソース名、およびパラメータ名の相互の関係をルールとして記述するルールファイルを格納するルールファイル格納手段、
   前記ルールファイルを参照して、前記要求項目に対してＡＰＩ規定に合わない箇所を検出するチェック実行手段、として機能させるためのプログラム。

Images