【Postman】 API通信で出てくる情報を初学者用にまとめてみた

Other,Postman

今回はAPI通信で出てくる情報を初学者用にまとめの紹介です。

APIに出てくる情報総まとめ

APIに出てくる情報総まとめです

関数または変数名中身内容
EndpointAPIのURLリソースにアクセスするためのURL
MethodHTTPメソッドGET, POST, PUT, DELETEなどのHTTP動詞
Headersリクエストヘッダー認証情報やコンテンツタイプの指定
ParametersクエリやリクエストパラメータAPIに渡すデータ
Request BodyリクエストボディPOSTやPUTで送信するデータの内容
Response Status Codeステータスコード200, 404, 500などのHTTP応答コード
Response BodyレスポンスボディAPIから返されるデータ
Authentication認証方法APIキー、トークン、ベーシック認証など
Rate Limitingレート制限APIの使用回数やリクエスト頻度の制限
Paginationページネーション大量のデータを分割して返す仕組み

エンドポイント

APIリクエストを送信するURLです。

https://example.com/api/v1/resource

スポンサードサーチ

HTTPメソッド

リクエストの種類を指定する方法です。

  • GET: データを取得する。
  • POST: データを新規作成する。
  • PUT: データを更新する。
  • DELETE: データを削除する。

リクエストヘッダー

API通信時に必要な追加情報です。

キー名用途補足
Authorization認証情報(トークンやAPIキー)を送信API認証のため最もよく使われるヘッダーの1つ。BearerやAPIキー形式が多い
Cache-Controlキャッシュの制御を指定リクエスト時にキャッシュ利用の可否を指定(例: no-cacheでキャッシュ無効)
Content-Typeリクエストのデータ形式を指定APIでapplication/jsonがほぼ標準。ファイル送信時はmultipart/form-data
Content-Lengthリクエストボディのサイズ(バイト数)を指定自動計算されることが多い(Postmanやブラウザでは不要)
Hostリクエスト先のホスト名(サーバーアドレス)を指定HTTP 1.1で必須。通常はサーバーが自動的に取得
User-Agentクライアント情報を送信APIクライアントやブラウザの情報を伝える。カスタマイズ可能
Acceptレスポンス形式の希望を指定JSONを期待する場合はapplication/jsonを指定するのが一般的
Accept-Encodingサーバーがサポートするデータ圧縮形式を指定gzip, deflate, brが一般的。データ量削減のため使用
Connection接続の管理方法を指定(例: keep-aliveで接続持続)通常keep-aliveで、持続的接続を確立するために使用される

認証用トークン、データ形式指定などがあります。

Content-Type: application/json
Authorization: Bearer token

送信データの形式を指定

Content-Typeは送信データの形式を指定です。

Content-Type: application/json

認証情報

Authorizationは認証するときはAuthorizationを使います。

Authorization: Bearer api_token

付与には必須ではに場合や自動付与などもあります

キー名自動付加必須必須ではない
Authorization×認証が必要な場合は必須認証が不要なAPIでは不要
Cache-Control××条件に応じて不要
Content-Type×ボディを送る場合は必須GETリクエストでは不要
Content-Length×(自動で計算されるため)手動で設定する必要は通常なし
HostHTTP/1.1では必須×
Accept多くのAPIで必須×
Accept-Encoding×圧縮が不要なら不要
Connection×通常は省略可能

Headersの補足

Content-Length

  • 自動計算される場合がほとんどで、手動で指定する必要は通常ありません。
  • リクエストボディがある場合に利用される。

Host

  • 通常、リクエストURLから自動的に計算される。
  • APIリクエストでは意識することが少ないが、プロキシやロードバランサーを使用している場合に役立つ。

Connection

  • keep-aliveは持続的接続(複数のリクエストを同じ接続で送る)を指定。
  • 一部のAPIでは明示的にcloseを指定する場合もある。

User-Agent

  • カスタマイズすることで、API提供側がアクセス元を区別可能。
  • 例: MyApp/1.0.0を設定すると、自社アプリからのリクエストであることを示せる。

Accept-Encoding

  • 圧縮形式(例: gzip)をサーバーに指定し、ネットワーク通信量を削減できる。
  • 圧縮が不要な場合、省略も可能。

スポンサードサーチ

Authorizationの種類

Authorizationの種類です

  1. Bearer Token Authentication
  2. API Key Authentication
  3. JWT (JSON Web Token)
  4. OAuth 2.0
  5. Basic Authentication
  6. Digest Authentication
  7. Hawk Authentication
  8. Custom Token Authentication
  9. Session-Based Authentication
  10. NTLM (Windows Authentication)

複数ありますがよく使われる、認証方法だけ覚えておけば大丈夫です!
その場の環境でキャッチアップすればいいと思います。

  1. Bearer Token Authentication:最も一般的
  2. API Key Authentication:シンプルな公開API向け
  3. JWT:セッションレス認証でモダンなアプリ向け
  4. OAuth 2.0:高度な認証・認可システムに必要

Bearer Token Authentication

APIのトークンベース認証します。

OAuth 2.0で発行されるアクセストークンやJWTします。

Authorization: Bearer api_token
  • トークンを事前に取得して使用
  • OAuth 2.0でよく利用される
  • トークンに有効期限を持たせることでセキュリティ向上
  • サーバー側でセッションを管理する必要がない

Bearer Token AuthenticationでJWTやOAuth 2.0とは?

認証のBearer Token AuthenticationでJWTやOAuth 2.0の認証の種類が入ってるのが意味が、わからない方へ補足です

概要

  • Bearer Tokenは「トークンを持つ者(Bearer)」がそのトークンを提示することでリソースにアクセスできるシステム
  • トークン自体がアクセス権を表し、サーバーがそのトークンを検証して認証・認可を行います

基本的な仕組み

  • クライアントがサーバーからトークンを取得します(通常は事前の認証や認可プロセスを経て発行される)。
  • クライアントは、そのトークンをリクエストヘッダーに含めてサーバーに送信します。
  • サーバーはトークンの有効性を検証し、リソースへのアクセスを許可または拒否します。
Authorization: Bearer access_token

Bearer Token AuthenticationとOAuth 2.0の関係

  • OAuth 2.0は、認証・認可を提供するプロトコル
    • OAuth 2.0を使うと、クライアントはアクセストークン(Bearer Token)を取得します
    • このアクセストークンを使ってリソースにアクセスする際に、Bearer Token Authenticationを使用します
  • 関係性:
    • Bearer Token Authenticationは、OAuth 2.0の一部の仕組みとして利用される認証方式です
    • OAuth 2.0がトークンを発行し、Bearer Token Authenticationがそのトークンを使用する

Bearer Token AuthenticationとJWTの関係

  • JWTは、トークンの形式を定義するデータ構造
    • JWTはJSON形式で情報(クレーム)を持つ自己完結型のトークンで、データは署名付きで改ざん防止されています
    • Bearer TokenとしてJWTが使われることが一般的です
  • 関係性:
    • Bearer Token Authenticationは「トークン自体の利用方法」に焦点を当てています
    • JWTは「トークンの中身」に焦点を当てています

Bearer Token Authenticationを単体で使う場合

  • Bearer Token Authenticationは、OAuth 2.0やJWTがなくても使えます。
    • :
      • シンプルなAPI認証で、トークンは固定値(例えば、APIキー)として利用
      • サーバー側でトークンをデータベースで管理し、有効性をチェック

まとめ

  • Bearer Token Authenticationは「トークンを送信して認証する仕組み」
  • OAuth 2.0やJWTはトークンを発行・管理するための別の仕組み
  • Bearer Token Authenticationは、それらの仕組みで発行されたトークンを利用する方法の1つとして広く使われています

よく使われる場面

  • ソーシャルログイン(Google, Facebook, Twitterなど)
  • 外部APIの認証

API Key Authentication

APIキーを送信するだけで認証できます。

複雑な認証フローOAuth 2.0が不要で、Google Maps API、OpenWeather APIなど、サードパーティAPIなど公開APIなどでよく使われる軽量な認証システムでよく利用します。

Authorization: Token api_key
  • 実装が簡単でクライアントアプリでも利用しやすい
  • シンプルな認証が必要な場合に適している
  • HTTPSで通信を暗号化しないと、APIキーが盗まれるリスクが高い
  • 必要に応じて、APIキーの有効期限やアクセス範囲を制限します

よく使われる場面

  • 公開API
  • フロントエンドアプリやモバイルアプリからのAPIアクセス

JWT (JSON Web Token)

JSON形式のトークンを使ったセッションレスな認証です。
ユーザー認証やAPIアクセス制御で使われることが多いです。

SPA(Single Page Applications)などで使われます。

Authorization: Bearer jwt_token
  • 自己完結型トークン(データをトークン自体に含む)
  • サーバー側でのトークン管理が不要
  • 柔軟でスケーラブルなシステムに適している

よく使われる場面

  • SPA(Single Page Applications)
  • マイクロサービス間の通信

「マイクロサービス間の通信」とは、複数の小さなサービス(マイクロサービス)が連携してシステム全体を構成する際の通信を指します。

よく使われる場面

  1. ユーザー管理サービス
  2. 注文管理サービス
  3. 支払いサービス

OAuth 2.0

アクセストークンを発行し、高度な認証・認可システムにBearerトークンとして使用します。
GoogleやFacebookの認証フローで使用されます。

  • ユーザー認証後、アクセストークンを取得
  • トークンを使ってAPIにアクセス
  • セキュリティが高く、複雑な認証要件に対応可能。
Authorization: Bearer access_token
  • ソーシャルログインなどで利用。
  • セキュリティと利便性が高い。

よく使われる場面

  • サードパーティサービスの統合
  • ソーシャルログインやシングルサインオン(SSO)

リクエストボディ

POSTやPUTリクエストでサーバーにデータを送る際に使用します。
通常はJSON形式でサーバーに送ります。

{
    "name": "example",
    "email": "example@example.com"
}

スポンサードサーチ

クエリパラメータ

パラメータ名用途
api_keyAPIキー認証
pageページ番号指定(ページネーション)
limit取得件数の制限
q検索キーワード
sort並び順の指定

URLに追加して送信するデータです。
検索条件やフィルタなどで利用します。

resource?key=value

クエリパラメーターが複数あれば「&」で区切ることができます。

https://example.com/api/v1/resource?key=value&other_key=other_value
  • resource: APIのエンドポイント(データや機能の場所)。
  • ?: クエリパラメータの開始を示す。
  • key=value: パラメータの1つ目。keyという名前にvalueが割り当てられている。
  • &: 複数のパラメータを区切るための文字。
  • other_key=other_value: パラメータの2つ目。other_keyにother_valueが割り当てられている。

レスポンス

サーバーが返すデータです。

ステータスコード

  • 200: 成功
  • 400: クライアントエラー (リクエストが不正)
  • 401: 認証エラー
  • 500: サーバーエラー

レスポンスヘッダー

  • Content-Type: レスポンスデータの形式 (例: application/json)

レスポンスボディ

  • データがJSONやXML形式で返ることが多い。

エラーハンドリング

サーバーからのエラーを処理します。
タイムアウトや接続エラーへの対応です。
ステータスコードによるエラー分類します。

  • 404エラー時に「データが見つからない」と表示。

通信のセキュリティ

通信のセキュリティです。
HTTPSで暗号化、IP制限やトークン有効期限を設定します。

以上でAPIの学習は終了です。

Other,PostmanPostman

Posted by kami