【実務・中級編】 Swagger UIによるAPIドキュメントの自動生成と対話的テスト – Web APIアーキテクチャ・データ連携実践ガイド

皆さん、こんにちは！ネットワークの深淵に魅入られた男、プロトコル専門家の私がお届けする技術ブログの時間です。今日もまた、パケットが織りなす壮大なドラマと、その裏側にある泥臭い現場の知恵を、皆さんと分かち合いたいと思います。

今日のテーマは、Web API開発において、もはや手放せない存在となったOpenAPIとSwagger UI、そして認証フローの統合から対話的テストまで、その実用的な活用術に迫ります。

API開発の現場で、こんな経験はありませんか？

  • 「ドキュメントと実際のAPIの挙動が違うんだけど…」
  • 「このAPI、どうやって認証すればいいんだっけ？」
  • 「テストするために、毎回curlコマンドを組み立てるのが面倒だ…」

私も若かりし頃は、古びたWikiページを漁り、時にはソースコードを覗き込み、挙げ句の果てには直接開発者に「これってどういう動きするんですか？」と聞き回る…なんてことが日常茶飯事でした。しかし、OpenAPIとSwagger UIが登場して以来、そんな苦労は過去のものとなりつつあります。

OpenAPIとSwagger UIでAPI開発に革命を！認証フロー統合から対話テストまで、現場の知恵を徹底解説

1. APIドキュメンテーションの苦悩とOpenAPIの救済

かつて、APIドキュメントは「書くのが面倒、更新が滞りがち、そしてすぐに陳腐化する」という負のサイクルに囚われていました。開発者がAPIの変更を加えるたびに、手動でドキュメントを更新する手間は大きく、結果としてドキュメントと実際のAPIの間に乖離が生じ、それがまた新たなトラブルの温床となる…。この悪循環は、多くのプロジェクトで開発効率を低下させる要因となっていました。

ここに救いの手を差し伸べたのが、OpenAPI Specification (OAS) です。

OpenAPI Specification (OAS) とは何か？

OpenAPI Specification（旧Swagger Specification）は、RESTful APIを機械判読可能な形式で記述するための言語に依存しない標準です。これは単なるドキュメントフォーマットではなく、APIの「契約」を定義するものです。

その記述には、主に YAML または JSON フォーマットが用いられます。これらのフォーマットは、それぞれRFC 7159（JSON）やRFC 8259（JSONの代替となるRFC）に準拠しており、人間にも読みやすく、かつコンピュータにも解析しやすい構造を持っています。

OpenAPI定義ファイルには、以下のような情報が記述されます。

  • APIの基本情報: タイトル、バージョン、説明など
  • サーバー情報: APIのベースURL
  • エンドポイント: パス、HTTPメソッド（GET, POST, PUT, DELETEなど）
  • リクエスト: パラメータ（パス、クエリ、ヘッダー、クッキー）、リクエストボディのスキーマ
  • レスポンス: 各ステータスコード（例: 200 OK, 400 Bad Request）に対するレスポンスボディのスキーマ
  • 認証スキーム: APIキー、OAuth2、HTTP Basic認証など
  • スキーマ定義: APIが使用するデータモデル（オブジェクト構造）

このOpenAPI定義ファイルがあることで、APIの設計、開発、テスト、ドキュメンテーション、そしてクライアントコードの生成に至るまで、開発ライフサイクルの様々なフェーズで一貫性のある情報源として機能するのです。

2. Swagger UIが提供する「インタラクティブな窓」

OpenAPI定義がAPIの「設計図」だとすれば、Swagger UI はその設計図を基に、誰もが直感的にAPIを理解し、操作できる「インタラクティブなユーザーインターフェース」を提供するツールです。

Swagger UIの魅力と機能

Swagger UIは、ブラウザ上で動作するWebアプリケーションとして提供され、OpenAPI定義ファイルを読み込むことで、以下のような機能を自動生成します。

1. エンドポイント一覧の表示: 定義されているすべてのAPIパスとHTTPメソッドが、分かりやすくツリー形式で表示されます。
2. 詳細なスキーマ表示: 各エンドポイントのリクエストパラメータ、リクエストボディ、そしてレスポンスボディの構造が、データ型や必須/任意といった情報と共に詳細に表示されます。
3. 「Try it out」機能: これがSwagger UIの最大の魅力と言っても過言ではありません。表示されているAPIエンドポイントに対して、ブラウザ上から直接リクエストを送信し、そのレスポンスをリアルタイムで確認できます。

パケットレベルでの動き

Swagger UIがブラウザに表示されるとき、背後では何が起こっているのでしょうか？

1. 初期ロード: クライアント（Webブラウザ）は、サーバーからSwagger UIのHTML, CSS, JavaScriptファイルをダウンロードします。
2. OpenAPI定義の読み込み: Swagger UIのJavaScriptは、指定されたOpenAPI定義ファイル（openapi.yamlやopenapi.jsonなど）を非同期で読み込みます。
3. UIのレンダリング: 読み込んだOpenAPI定義を解析し、それを基にAPIのエンドポイント、パラメータ、スキーマなどを整形してブラウザ上に表示します。
4. 「Try it out」の実行: ユーザーが「Try it out」ボタンをクリックし、パラメータを入力して「Execute」ボタンを押すと、Swagger UIのJavaScriptが内部的にHTTPリクエストを構築します。

  • このHTTPリクエストは、ユーザーのブラウザから直接、対象のAPIサーバーへ送信されます。
  • レスポンスを受け取ると、Swagger UIはその内容を整形してブラウザ上に表示します。

つまり、Swagger UI自体はプロキシとして機能するわけではなく、あくまでブラウザ上でAPIリクエストを構築・送信し、その結果を表示するためのクライアントサイドツールなのです。

3. 現場で必須！認証フローの統合と対話的テスト

APIを「叩く」上で、認証は避けて通れない関門です。特に本番環境に近いAPIでは、ほとんどの場合、何らかの認証機構が導入されています。Swagger UIで対話的にテストする際も、この認証フローをスムーズに統合できるかが鍵となります。

OpenAPI Specificationは、様々な認証スキームを定義する能力を持っています。Swagger UIは、これらの定義を認識し、ユーザーが認証情報を入力・適用できるUIを提供します。

Swagger UIでの認証設定 (securitySchemes と security キー)

OpenAPI定義ファイル内で、APIが利用する認証方法を components/securitySchemes キーの下で定義します。そして、特定のエンドポイントやAPI全体にその認証を適用するために security キーを使用します。

代表的な認証スキームをいくつか見てみましょう。

1. HTTP Basic認証 (RFC 7617):
ユーザー名とパスワードをBase64エンコードし、Authorization ヘッダーに Basic <credentials> の形式で含める最も基本的な認証方式です。

2. Bearer Token認証 (OAuth 2.0 / RFC 6750):
OAuth 2.0などで発行されるアクセストークンを Authorization ヘッダーに Bearer <token> の形式で含める認証方式です。JWT（JSON Web Token）などがよく利用されます。

3. API Key認証:
APIキーを、ヘッダー、クエリパラメータ、またはクッキーとして送信する認証方式です。

では、openapi.yaml でこれらの認証スキームを定義する例を見てみましょう。

# openapi.yaml
openapi: 3.0.0
info:
  title: My Awesome API
  version: 1.0.0
  description: これは私が丹精込めて作り上げたAPIです。
servers:
  - url: https://api.example.com/v1 # APIのベースURL
    description: 本番環境APIサーバー

paths:
  /users:
    get:
      summary: 全ユーザー情報を取得します
      description: 認証済みのユーザーのみアクセス可能です。
      security: # このエンドポイントに適用する認証スキームを指定
        - bearerAuth: [] # bearerAuth (securitySchemesで定義した名前) を適用
      parameters:
        - name: limit
          in: query
          description: 取得するユーザーの最大数
          required: false
          schema:
            type: integer
            format: int32
            default: 10
      responses:
        '200':
          description: ユーザーリスト
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
        '401':
          description: 認証が必要です
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        '403':
          description: 権限がありません
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    post:
      summary: 新しいユーザーを作成します
      description: 管理者権限を持つユーザーのみ可能です。
      security:
        - basicAuth: [] # basicAuth を適用
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewUser'
      responses:
        '201':
          description: ユーザー作成成功
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '400':
          description: リクエストボディが不正です
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

components:
  securitySchemes: # ここで認証スキームを定義します
    basicAuth: # 任意の名前 (後でsecurityキーで参照)
      type: http
      scheme: basic # HTTP Basic認証
      description: ユーザー名とパスワードによるHTTP Basic認証
    bearerAuth: # 任意の名前
      type: http
      scheme: bearer # Bearer認証
      bearerFormat: JWT # JWTトークンを使用する場合
      description: JWTアクセストークンによる認証。AuthorizationヘッダーにBearerトークンを含めます。
    apiKeyAuth: # 任意の名前
      type: apiKey
      in: header # APIキーをHTTPヘッダーに含める
      name: X-API-KEY # ヘッダー名
      description: カスタムヘッダーX-API-KEYによるAPIキー認証です。
    cookieAuth: # 任意の名前
      type: apiKey
      in: cookie # APIキーをクッキーに含める
      name: SESSIONID # クッキー名
      description: セッションIDクッキーによる認証です。
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer
          format: int64
          description: ユーザーID
        name:
          type: string
          description: ユーザー名
        email:
          type: string
          format: email
          description: メールアドレス
      required:
        - id
        - name
        - email
    NewUser:
      type: object
      properties:
        name:
          type: string
          description: 新しいユーザーの名前
        email:
          type: string
          format: email
          description: 新しいユーザーのメールアドレス
      required:
        - name
        - email
    Error:
      type: object
      properties:
        code:
          type: integer
          format: int32
          description: エラーコード
        message:
          type: string
          description: エラーメッセージ
      required:
        - code
        - message

Authorize ボタンの挙動とトークンの設定方法

上記の openapi.yaml をSwagger UIが読み込むと、画面右上に Authorize (または Available authorizations) ボタンが表示されます。

1. Authorize ボタンのクリック:
このボタンをクリックすると、OpenAPI定義で securitySchemes に定義した認証方式（basicAuth, bearerAuth, apiKeyAuthなど）が一覧表示されます。
2. 認証情報の入力:

  • basicAuth の場合は、ユーザー名とパスワードを入力するフィールドが表示されます。
  • bearerAuth の場合は、アクセストークン（JWTなど）を入力するフィールドが表示されます。
  • apiKeyAuth の場合は、APIキーを入力するフィールドが表示されます。

3. 認証情報の適用:
入力した認証情報を適用すると、その情報がSwagger UIのセッションに保存されます。その後、「Try it out」でAPIリクエストを送信する際、Swagger UIは自動的に適切な Authorization ヘッダーやその他の認証関連情報をリクエストに含めてくれます。

これにより、開発者は煩雑な認証情報の管理から解放され、純粋にAPIの挙動テストに集中できるようになるわけです。

4. 実践！Swagger UIでAPIを叩き、挙動を確認する

それでは、実際にSwagger UIを使ってAPIを叩き、その挙動を確認するプロセスを見ていきましょう。

GETリクエストの簡単な実行例

1. Swagger UIで /users の GET メソッドを展開します。
2. Try it out ボタンをクリックします。
3. limit パラメータに 5 などの値を入力します。（OpenAPI定義で security が設定されている場合、先に Authorize ボタンでトークンを設定しておく必要があります）
4. Execute ボタンをクリックします。

すると、Swagger UIは以下の情報を表示します。

  • Curlコマンド: 実際に送信されたリクエストと等価な curl コマンドが表示されます。これはデバッグや他のツールでの再現に非常に役立ちます。
  • Request URL: 実際にリクエストが送信されたURL。
  • Request Headers: 送信されたHTTPヘッダー。認証情報もここに表示されます。
  • Response Body: APIからのレスポンスボディ（JSONなど）。
  • Response Headers: APIからのレスポンスヘッダー。
  • Response Code: HTTPステータスコード（例: 200, 401）。

この一連の流れは、ブラウザの開発者ツール（F12キーで開くことが多い）の「Network」タブで実際にHTTPリクエストが飛んでいることを確認できます。パケットレベルでは、ブラウザがAPIサーバーに対してHTTP/1.1 (またはHTTP/2) の GET メソッドでリクエストを送り、サーバーはそれに応じたレスポンスボディとステータスコードを返す、というシンプルなシーケンスです。

認証トークンを設定した後の Try it out の実行例

Authorize ボタンでBearerトークンを設定した場合、/users の GET リクエストを実行すると、Request Headers に以下のような Authorization ヘッダーが自動的に追加されているのが確認できます。

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

これがRFC 6750で定義されるBearer認証の形式です。APIサーバーはこのヘッダーを解析し、トークンの有効性を検証することで、クライアントの認証状態を判断します。

等価なコード例で理解を深める

Swagger UIは非常に便利ですが、プログラムからAPIを叩く際のイメージを持つためにも、curl、Python、JavaScriptでの等価なリクエスト例を見てみましょう。

1. curl コマンドでの実行例

最も手軽にHTTPリクエストを送信できるCLIツールです。

# Bearerトークン認証を伴うGETリクエストの例
# -X GET: HTTPメソッドをGETに指定
# -H "Authorization: Bearer ...": AuthorizationヘッダーにBearerトークンを設定
# -H "Accept: application/json": レスポンスとしてJSON形式を期待する
# "https://api.example.com/v1/users?limit=5": APIのエンドポイントURLとクエリパラメータ
curl -X GET \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c" \
  -H "Accept: application/json" \
  "https://api.example.com/v1/users?limit=5"

# HTTP Basic認証を伴うPOSTリクエストの例
# -X POST: HTTPメソッドをPOSTに指定
# -H "Authorization: Basic ...": AuthorizationヘッダーにBase64エンコードされた認証情報を設定
# -H "Content-Type: application/json": リクエストボディのタイプをJSONに指定
# -d '{...}': リクエストボディのデータ
curl -X POST \
  -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "alice@example.com"}' \
  "https://api.example.com/v1/users"

2. Python requests ライブラリでの実行例

PythonでAPIを扱うなら requests ライブラリが定番です。

import requests
import base64

# Bearerトークン
bearer_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
# APIエンドポイント
base_url = "https://api.example.com/v1"

# GETリクエストの実行
def get_users(limit=10):
    headers = {
        "Authorization": f"Bearer {bearer_token}", # BearerトークンをAuthorizationヘッダーに設定
        "Accept": "application/json"              # レスポンス形式を指定
    }
    params = {
        "limit": limit                            # クエリパラメータ
    }
    response = requests.get(f"{base_url}/users", headers=headers, params=params)
    response.raise_for_status() # HTTPエラーが発生した場合に例外を発生させる
    return response.json()

# HTTP Basic認証を伴うPOSTリクエストの実行
def create_user_basic_auth(username, password, name, email):
    # ユーザー名とパスワードをBase64エンコード
    credentials = f"{username}:{password}".encode("ascii")
    base64_credentials = base64.b64encode(credentials).decode("ascii")

    headers = {
        "Authorization": f"Basic {base64_credentials}", # Basic認証情報をAuthorizationヘッダーに設定
        "Content-Type": "application/json",             # リクエストボディの形式を指定
        "Accept": "application/json"                    # レスポンス形式を指定
    }
    data = {
        "name": name,
        "email": email
    }
    response = requests.post(f"{base_url}/users", headers=headers, json=data)
    response.raise_for_status()
    return response.json()

if __name__ == "__main__":
    try:
        print("--- Getting users with Bearer Token ---")
        users = get_users(limit=3)
        print(users)

        print("\n--- Creating user with Basic Auth ---")
        new_user = create_user_basic_auth("admin", "password", "Bob", "bob@example.com")
        print(new_user)

    except requests.exceptions.HTTPError as e:
        print(f"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(f"An error occurred: {e}")

3. JavaScript Fetch API での実行例

Webフロントエンド開発でよく使われる Fetch API です。

// Bearerトークン
const bearerToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c";
// APIエンドポイント
const baseUrl = "https://api.example.com/v1";

// GETリクエストの実行
async function getUsers(limit = 10) {
    const url = new URL(`${baseUrl}/users`);
    url.searchParams.append("limit", limit); // クエリパラメータを追加

    const response = await fetch(url, {
        method: "GET",
        headers: {
            "Authorization": `Bearer ${bearerToken}`, // BearerトークンをAuthorizationヘッダーに設定
            "Accept": "application/json"              // レスポンス形式を指定
        }
    });

    if (!response.ok) { // HTTPステータスコードが200番台以外の場合
        throw new Error(`HTTP error! status: ${response.status} - ${await response.text()}`);
    }
    return response.json();
}

// HTTP Basic認証を伴うPOSTリクエストの実行
async function createUserBasicAuth(username, password, name, email) {
    // ユーザー名とパスワードをBase64エンコード
    const credentials = btoa(`${username}:${password}`); // btoaはBase64エンコード関数

    const response = await fetch(`${baseUrl}/users`, {
        method: "POST",
        headers: {
            "Authorization": `Basic ${credentials}`,    // Basic認証情報をAuthorizationヘッダーに設定
            "Content-Type": "application/json",         // リクエストボディの形式を指定
            "Accept": "application/json"                // レスポンス形式を指定
        },
        body: JSON.stringify({ // リクエストボディをJSON文字列に変換
            name: name,
            email: email
        })
    });

    if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status} - ${await response.text()}`);
    }
    return response.json();
}

// 実行例
(async () => {
    try {
        console.log("--- Getting users with Bearer Token ---");
        const users = await getUsers(3);
        console.log(users);

        console.log("\n--- Creating user with Basic Auth ---");
        const newUser = await createUserBasicAuth("admin", "password", "Charlie", "charlie@example.com");
        console.log(newUser);

    } catch (error) {
        console.error("An error occurred:", error);
    }
})();

これらのコード例は、Swagger UIの「Try it out」機能が内部でどのようなHTTPリクエストを構築し、送信しているかを示しています。Swagger UIでうまくいかない場合や、より詳細なデバッグが必要な場合は、これらの等価なコードを使って問題の切り分けを行うのが常套手段です。

エラーハンドリングとデバッグのヒント

APIの挙動確認において、エラーハンドリングは非常に重要です。

  • HTTPステータスコード: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error など、APIからの応答で返されるステータスコードは、問題の原因を特定する上で最初のヒントとなります。
  • レスポンスボディ: エラーが発生した場合、APIはエラーの詳細をレスポンスボディに含めて返すことが多々あります。例えば、{"code": 1001, "message": "Invalid API Key"} のようなJSON形式です。Swagger UIのレスポンスボディをしっかり確認しましょう。
  • 開発者ツール (Networkタブ): ブラウザの開発者ツールのNetworkタブは、Swagger UIが生成した実際のHTTPリクエスト（ヘッダー、ボディ、タイミングなど）を詳細に確認できる強力なツールです。認証情報が正しく送られているか、リクエストボディがOpenAPI定義通りかなどをここで検証できます。

5. OpenAPI定義の管理とCI/CDパイプラインへの組み込み

OpenAPI定義は、一度作って終わりではありません。APIの進化と共に、定義もまた更新されていくべきものです。

OpenAPI定義をどう管理するか

  • コードリポジトリでの管理: openapi.yaml や openapi.json ファイルは、APIのソースコードと共にGitなどのバージョン管理システムで管理するのがベストプラクティスです。これにより、APIの変更履歴と定義の変更履歴を紐付けられます。
  • レビュープロセス: APIの変更と同時にOpenAPI定義も更新し、コードレビューの一環として定義の正確性をレビューします。
  • 単一ソースの原則: APIの設計、実装、ドキュメンテーションは、OpenAPI定義を唯一の信頼できる情報源（Single Source of Truth）として構築することが理想です。

CI/CDパイプラインでの自動生成・デプロイ

OpenAPI定義は、CI/CDパイプラインに組み込むことで、その価値を最大限に引き出せます。

1. lintツールによる定義の検証:
spectral や swagger-cli といったツールを使って、OpenAPI定義が仕様に準拠しているか、スタイルガイドに合致しているかを自動で検証できます。

# Spectralを使用したOpenAPI定義の検証例
    # spectral install && spectral lint openapi.yaml
    # GitHub ActionsやGitLab CIなどでこのコマンドを実行し、定義の整合性を自動チェック

2. Swagger UIのデプロイ戦略:

  • APIサーバーに組み込み: Express.js (Node.js) や Spring Boot (Java) など、多くのフレームワークがSwagger UIを簡単に組み込むためのライブラリを提供しています。APIサーバーの特定のパス（例: /api-docs）でSwagger UIをホストします。
  • 静的サイトとしてデプロイ: OpenAPI定義ファイルをS3のようなストレージに置き、Swagger UIのHTML/JSファイルをCDN経由で配信する構成も可能です。これにより、APIサーバーとは独立してドキュメントを公開できます。
  • CI/CDでの自動生成と更新: APIコードのデプロイと連動して、最新のOpenAPI定義からSwagger UIを自動生成し、ドキュメントサーバーにデプロイするパイプラインを構築します。

モックサーバーの活用

OpenAPI定義は、モックサーバーを自動生成するツール（例: Prism）の入力としても利用できます。フロントエンド開発者は、バックエンドAPIが完成するのを待つことなく、OpenAPI定義から生成されたモックAPIに対して開発を進めることができます。これもまた、開発のスピードアップに大きく貢献する強力なツールです。

6. まとめと今後の展望

OpenAPI SpecificationとSwagger UIは、Web APIエコシステムにおいて、もはや必要不可欠な存在となりました。

  • 開発者にとって: APIの仕様を直感的に理解し、コードを書くことなく対話的にテストできるため、開発効率が飛躍的に向上します。特に認証が絡むAPIテストの煩雑さを解消する効果は絶大です。
  • 運用者にとって: APIの仕様が明確に定義されることで、トラブルシューティング時の問題特定が容易になり、外部連携の際のコミュニケーションコストも削減されます。
  • 組織全体にとって: APIの品質向上、開発サイクルの短縮、そしてドキュメントの信頼性確保に大きく貢献し、API中心のアーキテクチャを強力に推進します。

私が長年ネットワークの現場で見てきた「仕様書と実機が違う」「ドキュメントが更新されない」といった古典的な問題は、OpenAPIのような「機械が解釈できる仕様」と、Swagger UIのような「人間が直感的に操作できるインターフェース」の組み合わせによって、着実に解決されつつあります。

APIは、現代のシステム連携の基盤です。その設計、開発、運用において、OpenAPIとSwagger UIを最大限に活用し、より堅牢で、より使いやすく、そして何よりも「美しい」APIを構築していくことが、私たちエンジニアの使命だと私は信じています。

今日の解説が、皆さんのAPI開発・運用の一助となれば幸いです。また次回の記事でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました