Web・API / Web/API
APIとは
Application Programming Interface。アプリケーション同士が決まった形式でやり取りするための接点です。
用語集内のカードを見る詳細な図解
クライアントエンドポイントへ要求
認証/認可トークンやキーを検証
API処理入力を検証して処理
応答/監査ステータスとログを返す
- 認証と認可を分ける
- レート制限を確認
- エラー情報を出しすぎない
この記事で学べること
APIを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
- APIを読むときの前提
- 認証と認可を分ける
- 入力とエラー応答を見る
- レート制限と監査ログを運用に入れる
- 変更証跡と引き継ぎ
実務メモ
認証、認可、入力検証、監査ログを同じ単位で確認する
どこで効くか
APIはSaaS連携、管理自動化、診断API、監視連携、SPAのバックエンド呼び出しで効きます。障害、権限不足、レート制限、情報露出調査で確認します。
残す証跡
証跡にはAPI URL、メソッド、認証方式、権限、リクエストID、ステータス、エラーコード、レート制限ヘッダー、実行者、監査ログを残します。
避けたい誤解
疎通成功だけではAPI品質は判断できません。認証と認可の混同、入力検証不足、過剰なエラー情報、リトライ過多、監査ログ不足が運用時に問題化します。変更時は互換性と利用者影響も確認します。
まず確認すること
- 認証と認可を分けて確認する
- 異常系レスポンスと情報露出を確認する
- レート制限と監査ログを確認する
APIを読むときの前提
API（Application Programming Interface）は、アプリケーション同士が決まった形式でやり取りするための接点です。SaaS連携、管理自動化、診断API、監視連携、フロントエンドのバックエンド呼び出しで使います。
実務では、エンドポイント、メソッド、認証、認可、入力検証、レート制限、エラー応答、監査ログ、CORS、バージョン互換性を確認します。
証跡には、API URL、メソッド、リクエストID、認証方式、ステータス、レスポンス本文、エラーコード、実行者、レート制限ヘッダー、確認時刻を残します。
認証と認可を分ける
APIが「誰か」を確認できても、その利用者やアプリが対象操作を実行してよいとは限りません。認証と認可を分けて確認します。
APIキー、JWT、OAuth、サービスアカウントでは、権限範囲、期限、発行者、失効方法が異なります。管理APIでは読み取りと変更の権限を分けます。
- 認証方式を確認する。
- 操作ごとの権限を確認する。
- 失効や無効化の手順を確認する。
入力とエラー応答を見る
APIは、正常系だけでなく異常系が重要です。入力検証が弱いと不正な値、過大なデータ、型不一致、SQLインジェクションなどにつながります。
エラー応答では、内部パス、SQL、スタックトレース、シークレット、個人情報を出しすぎないようにします。一方で運用者が追えるエラーコードやRequest IDは必要です。
- 必須項目、型、長さを確認する。
- エラー時の情報露出を確認する。
- Request IDでログを追えるか確認する。
レート制限と監査ログを運用に入れる
APIは自動化から大量に呼ばれます。レート制限、タイムアウト、リトライ、バックオフ、429応答の扱いを決めておかないと、障害時に負荷を増やします。
監査ログには、誰が、いつ、どの対象へ、どの操作をしたかを残します。機密値やリクエスト本文を丸ごと保存しないようにします。
- レート制限ヘッダーを確認する。
- リトライ方針を確認する。
- 監査ログの項目とマスクを確認する。
変更証跡と引き継ぎ
API対応では、仕様、認証方式、権限、入力制約、エラー応答、ログ、制限値、互換性を残します。クライアントとサーバーの変更タイミングがずれることが多いためです。
引き継ぎでは、API担当、フロントエンド担当、運用担当、関連語としてAPIキー、JWT、OAuth、HTTPヘッダー、CORSを残すと確認しやすくなります。
- 代表リクエストと応答を保存する。
- 破壊的変更の有無を明記する。
- 監査ログで追えることを確認する。
関連語
同じ主要カテゴリの用語
Web・APIの学習順
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。