APIで記事一覧を取得できても、新規作成や更新までできると確認したことにはなりません。読む操作と書く操作を分け、どこまで試したかを記録します。認証情報そのものを記事やログへ掲載する必要はありません。
操作ごとに確認する
通信の公開仕様では、取得などのメソッドに役割が定義されています。取得が成功したという一回の結果は、別の操作の権限を証明しません。認証の有無、利用者の権限、対象の制限を分けて調べます。
確認表
| 項目 | 記録する内容 |
|---|---|
| 接続先 | 対象環境が正しいか |
| 操作 | 取得・作成・更新など |
| 認証の方法 | 値を出さず方式だけ |
| 応答 | 状態コードと安全な説明 |
| 結果 | 対象が実際に変わったか |
架空の型です。公開情報を認証なしで読める接続先もあるため、取得成功だけで認証設定済みとは扱いません。
エラーを断定しない
拒否の応答があっても、特定の原因と決めつけず、設定資料と安全に確認できる応答内容を見ます。認証情報、権限、接続先、対象の制約などの候補を分けます。秘密の値を表示して調査する方法は避けます。
書き込みを試す条件
許可された対象と範囲で実行します。下書きなどで確認する場合も、作成先と削除・修正の扱いを先に決めます。本番の公開記事を動作確認のためだけに無断で変更しません。権限を広げる前に、必要な操作を限定します。
結果を確かめる
応答が成功でも、公開状態や内容を確認します。処理が受け付けられたことと、利用者に見える結果は別です。試した対象、応答、実際の状態を対応させて記録します。
確認結果を報告する例
架空の例として、一覧取得のみ試した場合は「読み取りは確認済み、書き込みは未確認」と書きます。作成の試験で下書きができたなら、下書き作成までの確認です。公開の権限や画像アップロードまで確かめたことにはしません。操作の種類を明記すれば、どこから次の確認を始めるかが分かります。
関連する確認
認証情報が使える範囲と公開処理と表示の確認を合わせて参照できます。

コメント