引き続き API プラグインについての調査を進めていきます。
前回やっと正常なAPIプラグインを導入することが出来ました。
今回はAPIプラグインに内包されている簡易テスト機能の動作確認です。
　
テスト機能には「Swagger」と云うフレームワークを使用しているようです。
初めて触る人間がざっと調べた感想では API 作成に向いたフレームワークの様ですね。
今後 WebAPI を触るには無視できない存在になりそうです。
まぁ、今回は「使ってますよ」と云う事だけ覚えておこうと思います（笑）
　
さて、テスト内容です。
細かいところまで調べだすと際限が無さそうです・・・
とりあえず大きく二つの項目があります。
　
■ CRUD
　ユーザーインターフェースとして備えるべき基本的な機能を示す用語です。
　簡単に言うと以下の基本4機能のですが、これらの頭文字ですね。
　
　　Create（生成）
　　Read（読み取り）
　　Update（更新）
　　Delete（削除）
　
　今回はデータベースへの基本機能の為、それぞれ以下の内容として読み替える形でしょう。
　
　　Create　⇒　Insert
　　Read　⇒　Select
　　Update　⇒　Update
　　Delete　⇒　Delete（但し、API モジュールは論理削除の為。実際には Update）
　
　
■ Authorization
　認証されたユーザーの権限を確認して適切なアクセス権の制限を付与することです。
　ザックリとした説明ををすると、EC-CUBEにと会員ログインしたときにログインした人向けの適切な情報が表示されることです。
　使用しているときには当たり前のようなことですし、作成する側としてもユーザーに意識させない作りが必要となります。
　
　簡単に言ってしまうと、今回のテスト環境でのテストを行う主目的となる部分ですね。
　　・管理者権限の情報を管理者にしか表示／編集させない。
　　・ログインした会員に、他人の会員情報が誤って表示されない。
　
　
上記の2項目に沿って簡単なテスト項目が設定されています。
詳細なテスト項目として以下のような分類がついています。
　
　■ CRUD
　　・GET
　　・POST
　　・PUT
　　・DELETE
　
　　それぞれのHTMLの送信メソッドは先ほどの「CRUD」の用語にて対応しているようです。
　　・GET　⇒　Read（読み取り）
　　・POST　⇒　Update（更新）
　　・PUT　⇒　Create（生成）
　　・DELETE　⇒　Delete（削除 実際にが論理削除）
　
　■ Authorization
　　・GET
　　・POST
　
　上記の GET POST は単純にHTMLの送信メソッドのことでした。
　
　
と云うことで、各項目の詳細は次回に確認して行きたいと思います。
まぁ、あくまでもテスト環境なのでテスト環境の詳細を見ても仕方ないのかもしれません。
・・・場合によっては省略して他の内容を進めるかも（笑）
　
それでは今回はここまでとさせて頂きます。