Pragmatic Payload-Driven API Design

เลิกสับสนกับ HTTP Status! สรุปแนวทางการออกแบบ API สไตล์ Pragmatic Payload-Driven

แยก Transport ออกจาก Business Logic, โครงสร้าง Standard Envelope และวิธีใช้ Status Code ให้เฉียบคม

สรุปประเด็นสำคัญ (BLUF): สถาปัตยกรรม Pragmatic Payload-Driven แยกชั้น Infrastructure ออกจาก Business Logic อย่างเด็ดขาด โดยสงวนรหัส HTTP 4xx/5xx ไว้สำหรับ Network และ Gateway เท่านั้น และให้ระบบตอบกลับด้วยกลุ่ม 2xx เสมอเมื่อผ่านกระบวนการฝั่ง Application พร้อมห่อหุ้มผลลัพธ์ด้วย Standard JSON Envelope { success, code, message, data, error } เพื่อตัดปัญหาความคลุมเครือของ 404/400 และช่วยให้ Frontend จัดการ Error ผ่าน Interceptor ได้อย่างเป็นระบบ

หนึ่งในข้อถกเถียงคลาสสิกของคนทำ Backend คือ "เราควรออกแบบ API แบบไหน?"

ระหว่างสาย Strict RESTful ที่พยายามผูกทุกอย่างเข้ากับ HTTP Status Code (เช่น หา User ไม่เจอให้ตอบ 404, เงินไม่พอให้ตอบ 400 หรือ 422) กับสาย Payload-Driven ที่ตอบ HTTP 200 เป็นหลักแล้วไปบอกสถานะข้างใน JSON

ปัญหาของ Strict RESTful คือ "ความคลุมเครือ" เช่น เมื่อ Frontend ได้รับ 404 Not Found คำถามคือ... ตกลงพิมพ์ URL ผิด (Endpoint ไม่มีอยู่จริง) หรือว่าหาข้อมูลใน Database ไม่เจอ? ความสับสนนี้ทำให้ฝั่ง Frontend ต้องเขียน try-catch ซ้อนทับกันวุ่นวายเพื่อดัก Error

บทความนี้จะขอเสนอแนวทางการออกแบบ API แบบ "Pragmatic Payload-Driven" (เน้นการใช้งานจริง) ที่ดึงข้อดีของทั้งสองฝั่งมาผสมกัน เพื่อให้ Backend ทำงานเป็นมาตรฐาน และ Frontend เอาไปต่อยอดได้ง่ายที่สุด

🏛️ หัวใจสำคัญ: แยก Infrastructure ออกจาก Business Logic

กฎเหล็กของสถาปัตยกรรมนี้คือ:

• HTTP Status Code: มีหน้าที่บอกสถานะของการส่งข้อมูล (Transport/Infrastructure) เท่านั้น
• Response Payload (JSON): มีหน้าที่บอกผลลัพธ์ของเงื่อนไขทางธุรกิจ (Business Logic)

ดังนั้น ตราบใดที่ Request วิ่งฝ่า API Gateway มาถึง Controller และระบบประมวลผลจนจบกระบวนการ (แม้ว่างานนั้นจะล้มเหลวเพราะผิดเงื่อนไขธุรกิจ เช่น เงินไม่พอ) เราจะถือว่า "การสื่อสารสำเร็จ" และตอบ HTTP 200 OK เสมอ

📋 โครงสร้างมาตรฐาน (Standard Envelope)

ทุกๆ API ที่ทำงานทะลุเข้าถึง Business Logic จะต้องตอบกลับด้วยโครงสร้าง JSON นี้เสมอ:

{
  "success": true,               // boolean บอกว่างานสำเร็จตามเงื่อนไขหรือไม่
  "code": "SUCCESS",             // Business Code (ตัวพิมพ์ใหญ่) สำหรับให้ Frontend ใช้เงื่อนไข
  "message": "Operation success",// ข้อความสำหรับ Developer หรือใช้แสดงให้ User ดู
  "data": { ... },               // ข้อมูลที่จะส่งกลับ หรือ null
  "error": null                  // รายละเอียดเพิ่มเติมกรณีเกิด Error
}

✨ ศิลปะการใช้กลุ่ม 2xx (Success Group)

เราจะไม่ตอบ { success: true, data: null } กลับไปทุกครั้งให้เปลือง Bandwidth แต่เราจะใช้ HTTP Status ในกลุ่ม 2xx มาช่วยสื่อความหมายให้คมขึ้น:

• 200 OK (ตอบกลับพร้อมข้อมูล):
  ใช้กับ Action ทั่วไปที่มีข้อมูลต้องส่งกลับ เช่น GET ข้อมูล, POST เพื่อสร้างข้อมูล (หรืออาจใช้ 201 Created ก็ได้ถ้าต้องการ)
• 204 No Content (สำเร็จแบบไม่ต้องพูดเยอะ):
  ใช้กับคำสั่งที่ Frontend รู้อยู่แล้วว่าผลลัพธ์คืออะไร เช่น DELETE /users/123 หรือการแก้ไขสถานะแบบ Fire-and-forget ถ้าลบสำเร็จ Backend แค่ตอบ 204 กลับไป (ไม่มี Response Body) เพื่อประหยัด Payload
• 202 Accepted (รับเรื่องแล้ว แต่ขอเวลาไปทำก่อน):
  ใช้กับงาน Asynchronous หรืองานที่ใช้เวลานาน เช่น สั่ง Export Report ล้านบรรทัด ระบบจะตอบ 202 พร้อมกับแนบ jobId กลับไปให้ Frontend ทำ Polling เช็คสถานะทีหลัง ป้องกันปัญหา Request Timeout

🛡️ การตีกรอบจำกัดกลุ่ม Non-Success Codes (4xx และ 5xx)

แม้เราจะบอกว่าใช้ 200 เป็นหลัก แต่เราไม่ได้ทิ้ง 4xx และ 5xx ไปเลย เราแค่ "ห้ามนำมาใช้กับ Business Logic" เด็ดขาด โค้ดกลุ่มนี้จะถูกปล่อยให้เป็นหน้าที่ของ Framework, API Gateway หรือ Middleware เป็นคนจัดการ:

• 400 Bad Request (Client ส่งของพังมา):
  ใช้เมื่อ Request ผิดรูปแบบตั้งแต่ยังไม่เข้า Logic เช่น ส่ง JSON Syntax พังๆ หรือ Schema Validation ไม่ผ่าน (ลืมส่งฟิลด์บังคับ)
• 401 Unauthorized (คุณเป็นใคร?):
  ใช้เมื่อไม่มี Access Token หรือ Token หมดอายุ
• 403 Forbidden (รู้ว่าคือใคร แต่ไม่ให้เข้า):
  ใช้เมื่อ Token ถูกต้อง แต่ User คนนั้นไม่มีสิทธิ์ (Permission/Role) ในการเข้าถึง Endpoint นี้
• 404 Not Found (มาผิดซอย):
  มีความหมายเดียวเท่านั้นคือ "URL ผิด หรือ ไม่มี Endpoint นี้" (จะไม่ใช้กับกรณี Query ข้อมูลใน Database ไม่เจอเด็ดขาด ถ้าหาข้อมูลไม่เจอให้ตอบ 200 OK + data: null)
• 429 Too Many Requests:
  โดน Rate Limit บล็อกการยิง API ถี่เกินไป
• 500 Internal Server Error (Backend พังเอง):
  Database ล่ม, ระบบ Crash, หรือเกิด Exception ที่ Developer ไม่ได้ดัก (Unhandled Error)

📊 สรุปตาราง Guideline การออกแบบครอบคลุมทุก Action

💻 ตัวอย่างการนำไปใช้จริงฝั่ง Frontend (Axios Interceptor)

ทีม Frontend สามารถเขียน HTTP Interceptor ให้ดัก 4xx/5xx ไว้จัดการปัญหาระดับ Network และปล่อยให้กลุ่ม 2xx วิ่งทะลุเข้าไปใน Component เพื่อเช็คเงื่อนไขธุรกิจได้อย่างเรียบง่าย:

import axios from 'axios';

const api = axios.create({ baseURL: 'https://api.example.com/v1' });

// Global Interceptor สำหรับดัก Error ระดับ Network / Gateway
api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response) {
      const { status } = error.response;
      if (status === 401) {
        window.location.href = '/login';
      } else if (status === 403) {
        alert('คุณไม่มีสิทธิ์เข้าถึงข้อมูลนี้');
      } else if (status >= 500) {
        alert('ระบบเซิร์ฟเวอร์ขัดข้อง กรุณาลองใหม่ภายหลัง');
      }
    }
    return Promise.reject(error);
  }
);

// การเรียกใช้ใน Component: ไม่ต้องมี try-catch ซ้อนทับ!
async function doTransfer(amount) {
  const res = await api.post('/transfer', { amount });
  
  if (!res.data.success) {
    if (res.data.code === 'NO_FUND') {
      openTopUpModal();
    } else {
      alert(res.data.message);
    }
    return;
  }
  
  alert('โอนเงินสำเร็จ!');
}

❓ คำถามที่พบบ่อย (FAQ)

🏁 บทสรุป

การออกแบบ API แบบ Pragmatic Payload-Driven ช่วยแก้ปัญหา "คอขวดของการจัดการ Error" ได้อย่างหมดจด

ทีม Frontend สามารถเขียน HTTP Interceptor (เช่น ใน Axios) ให้ดัก 4xx/5xx ไว้จัดการปัญหาระดับ Network (เช่น เด้งไปหน้า Login, โชว์หน้าเว็บล่ม) และปล่อยให้กลุ่ม 2xx วิ่งทะลุเข้าไปใน Component เพื่อเช็คแค่ if (!response.data.success) แล้วแสดงผลข้อความแจ้งเตือนทางธุรกิจได้อย่างสวยงาม โดยไม่ต้องเอา Business Logic ไปปนกับ Network Exception อีกต่อไป

告别 HTTP Status 混乱！实用 Payload-Driven API 设计指南

解耦传输层与业务逻辑、标准 JSON Envelope 规范与状态码精准分流

核心要点 (BLUF): Pragmatic Payload-Driven 架构彻底将传输层（HTTP Status Code）与业务逻辑（JSON Envelope）解耦。将 4xx/5xx 严格限制在网络、API Gateway 与协议级错误；只要应用层 Controller 正常执行完毕，一律返回 2xx 并使用统一的 { success, code, message, data, error } Envelope，消除 404/400 歧义并极大简化前端 try-catch 逻辑。

在后端工程领域，一个经典的争论从未停歇：“我们应该如何设计 RESTful API？”

一派是严格的 RESTful 派（试图将一切业务状态映射到 HTTP Status Code，例如查无此用户返回 404，余额不足返回 400 或 422）；另一派则是实用的 Payload-Driven 派（绝大多数接口统一返回 HTTP 200，在 JSON 内表达真实状态）。

严格 RESTful 最大的硬伤在于“歧义性”。当前端收到一个 404 Not Found 时，开发者无法判断到底是 URL 拼写错误（接口路由不存在），还是数据库中找不到对应记录？这种混淆迫使前端写满防御性的 try-catch。

本文介绍的 Pragmatic Payload-Driven（实用型载荷驱动）方案融合了两者的长处：既保持了后端标准的严密性，又赋予前端极致清晰的契约。

🏛️ 核心架构：解耦传输层 (Infrastructure) 与业务逻辑 (Business Logic)

本设计的黄金法则是：

• HTTP Status Code: 仅负责反映网络传输与基础设施层（Routing, Gateway, 协议校验）的状态。
• Response Payload (JSON): 仅负责表达业务规则与业务领域逻辑（Business Logic）的计算结果。

只要请求成功穿越 API Gateway 抵达 Controller 并完成处理（即便由于业务规则未通过，如余额不足或优惠券过期），“网络通信”本身就已经成功了，必须返回 2xx（如 200 OK）。

📋 标准 Envelope 结构

所有抵达应用业务逻辑的接口，均返回如下规范的 JSON 结构：

{
  "success": true,               // boolean: 业务规则是否执行成功
  "code": "SUCCESS",             // UPPERCASE 业务错误码，供前端分支判断
  "message": "Operation success",// 面向开发者调试或提示用户的消息
  "data": { ... },               // 返回的主体数据对象或数组 (可为 null)
  "error": null                  // 错误发生时的详细调试信息或上下文
}

✨ 2xx 成功状态码的精细运用

我们无需每次都盲目返回冗余的 Payload，而是巧妙使用 2xx 系列优化网络传输：

• 200 OK (携带数据返回): 用于常规查询与资源创建（GET、POST 返回新数据实体）。
• 204 No Content (操作完成无需 Body): 用于前端已明确结果的操作（如 DELETE /users/123 或状态更新），节省带宽。
• 202 Accepted (异步任务已排队): 耗时任务（如导出百万行报表）立即响应 202 并附带 jobId，供前端轮询，避免 Gateway 超时。

🛡️ 4xx 与 5xx 状态码的严格边界

非 2xx 状态码严禁用于表达业务逻辑失败，它们完全由 Framework、API Gateway 或 Middleware 处理：

• 400 Bad Request: 请求语法畸形，未通过 Schema Validation。
• 401 Unauthorized: 缺少 Access Token 或 Token 过期。
• 403 Forbidden: 身份已验证但缺乏该端点的 RBAC 权限。
• 404 Not Found: 仅代表“URL 错误或端点不存在”（严禁用于数据库查询无结果；查询无结果请返回 200 OK + data: null）。
• 429 Too Many Requests: 命中限流策略。
• 500 Internal Server Error: 数据库宕机、未捕获的系统异常。

📊 全场景 API 设计规范对照表

💻 前端实践：Axios Interceptor 模式

import axios from 'axios';

const api = axios.create({ baseURL: 'https://api.example.com/v1' });

// 全局拦截器处理传输层故障
api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response) {
      const { status } = error.response;
      if (status === 401) window.location.href = '/login';
      else if (status === 403) alert('权限不足');
      else if (status >= 500) alert('服务器异常');
    }
    return Promise.reject(error);
  }
);

// 组件内部只关注业务
async function handleTransfer(amount) {
  const res = await api.post('/transfer', { amount });
  if (!res.data.success) {
    if (res.data.code === 'NO_FUND') openTopUpModal();
    else alert(res.data.message);
    return;
  }
  alert('转账成功');
}

❓ 常见问题 (FAQ)

🏁 总结

Pragmatic Payload-Driven API 设计从根本上打通了前后端对接的痛点。通过在传输层与业务层之间建立明确的隔离，系统不仅更加健壮，也让前端摆脱了恼人的 try-catch 泥潭。

HTTPステータスの混乱に終止符！実用的Payload-Driven API設計ガイド

インフラ層とビジネスロジックの分離、標準JSON Envelope、ステータスコードの明確な役割分担

要約 (BLUF): Pragmatic Payload-Driven（実用的ペイロード駆動型）アーキテクチャは、インフラ輸送層（HTTPステータスコード）とビジネスロジック（JSON Envelope）を明確に分離します。4xx/5xxはネットワークやAPI Gateway、プロトコルエラーに厳格に限定し、アプリケーションが正常に処理を完了した場合は常に2xxと標準的な { success, code, message, data, error } を返却することで、404の曖昧さを排除しフロントエンドのエラーハンドリングを大幅に簡素化します。

バックエンド開発における最も古典的な議論の一つが、「APIはどのように設計すべきか？」という問いです。

一方には、すべての状態をHTTPステータスコードに厳密にマッピングしようとするStrict RESTful派（ユーザーが見つからない場合は404、残高不足には400や422を返す）が存在し、もう一方には、基本的にHTTP 200を返しJSON内部で状態を表現するPayload-Driven派が存在します。

Strict RESTfulの最大の弱点は「曖昧さ」です。フロントエンドが 404 Not Found を受け取ったとき、URLのスペルミス（Endpointが存在しない）なのか、それともデータベース内に該当レコードが存在しないのか判断できません。この曖昧さが、フロントエンドに何重もの try-catch を強いる原因となっていました。

本記事では、両者の利点を融合させた「Pragmatic Payload-Driven」設計手法を解説します。

🏛️ 基本方針：インフラ層とビジネスロジックの完全分離

本アーキテクチャの黄金律は以下の通りです：

• HTTP Status Code: データ転送およびインフラ（Routing, Gateway, Network）の状態のみを担当する。
• Response Payload (JSON): ビジネスルールおよびドメインロジックの実行結果のみを担当する。

リクエストがAPI Gatewayを通過してControllerに到達し、処理が正常に完了したならば（たとえ残高不足などビジネス要件で処理が失敗した場合であっても）、「通信そのものは成功」とみなし、常に 200 OK を返却します。

📋 標準Envelope構造

ビジネスロジック層に到達するすべてのAPIは、以下の標準JSON形式でレスポンスを返します：

{
  "success": true,               // boolean: ビジネス条件を満たしたか否か
  "code": "SUCCESS",             // 大文字のビジネスコード（フロントエンドの条件分岐用）
  "message": "Operation success",// 開発者向けデバッグ情報またはユーザー表示用メッセージ
  "data": { ... },               // 返却データオブジェクト、配列、または null
  "error": null                  // エラー発生時の詳細情報
}

✨ 2xx（成功グループ）の洗練された使い分け

通信量を削減しつつ意図を明確にするため、2xxグループを効果的に活用します：

• 200 OK (データ返却): GETクエリや、生成されたリソースを返すPOST処理。
• 204 No Content (データなしの完了通知): DELETE /users/123 やステータス更新など、フロントエンドに追加データが不要な操作。レスポンスボディを省略し帯域を節約します。
• 202 Accepted (非同期タスク受付): レポート出力など時間のかかる処理。直ちに202とともに jobId を返し、タイムアウトを防ぎます。

🛡️ 4xxおよび5xxコードの厳格な適用制限

4xx/5xxは「ビジネスロジックの失敗に使用することを固く禁止」し、FrameworkやAPI Gatewayの責務とします：

• 400 Bad Request: リクエスト構文エラー、Schema Validation不合格。
• 401 Unauthorized: Access Token未送信または有効期限切れ。
• 403 Forbidden: 認証済みだが当該Endpointへの権限（RBAC）がない。
• 404 Not Found: 「URLの誤りまたはEndpointが存在しない」ことのみを意味する（DB検索結果ゼロには絶対に使用せず、200 OK + data: null を返します）。
• 429 Too Many Requests: レートリミット制限。
• 500 Internal Server Error: DBクラッシュ、未処理の例外。

📊 API設計アクション別マトリクス

💻 フロントエンド実装例：Axios Interceptor

import axios from 'axios';

const api = axios.create({ baseURL: 'https://api.example.com/v1' });

// ネットワーク層のエラーをグローバルに処理
api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response) {
      const { status } = error.response;
      if (status === 401) window.location.href = '/login';
      else if (status === 403) alert('アクセス権限がありません');
      else if (status >= 500) alert('サーバー障害が発生しました');
    }
    return Promise.reject(error);
  }
);

// コンポーネント内ではビジネス条件のチェックのみ
async function handleTransfer(amount) {
  const res = await api.post('/transfer', { amount });
  if (!res.data.success) {
    if (res.data.code === 'NO_FUND') openTopUpModal();
    else alert(res.data.message);
    return;
  }
  alert('送金が完了しました');
}

❓ よくある質問 (FAQ)

🏁 まとめ

Pragmatic Payload-Driven API設計は、フロントエンドとバックエンドの連携摩擦を根本から解決します。インフラ層とビジネスロジックの責任境界を整えることで、保守性に優れた堅牢なシステムを構築できます。

Schluss mit HTTP-Status-Verwirrung! Pragmatisches Payload-Driven API-Design

Saubere Trennung von Transport & Business-Logik, Standard-JSON-Envelope und präzise Statuscodes

Das Wichtigste zuerst (BLUF): Pragmatic Payload-Driven API-Design entkoppelt die Infrastruktur-Transportebene (HTTP Status Codes) strikt von der Geschäftslogik (JSON Envelope). Reservieren Sie 4xx/5xx ausschließlich für Netzwerk-, Gateway- und Protokollfehler. Sobald die Applikationslogik fehlerfrei durchläuft, wird stets ein 2xx-Status mit einem einheitlichen { success, code, message, data, error } Envelope zurückgegeben, was Frontend-Fehlerbehandlung und verschachtelte try-catch-Blöcke drastisch vereinfacht.

Eine der hitzigsten Debatten in der Backend-Entwicklung dreht sich um eine scheinbar simple Frage: „Wie sollten wir unsere APIs gestalten?“

Auf der einen Seite steht das Strict RESTful-Lager, das jeden Anwendungszustand auf HTTP-Statuscodes abbilden möchte (z. B. 404 bei nicht gefundenem Datensatz, 400 oder 422 bei unzureichendem Kontoguthaben). Auf der anderen Seite steht das Payload-Driven-Lager, das nahezu immer HTTP 200 zurückgibt und den Status komplett im JSON-Body kapselt.

Die größte Schwachstelle des strikten REST-Ansatzes in der Praxis ist die Mehrdeutigkeit. Erhält das Frontend ein 404 Not Found, stellt sich die Frage: Wurde die URL falsch geschrieben (Endpoint existiert nicht) oder existiert der Datensatz in der Datenbank nicht? Diese Unklarheit zwingt Frontend-Entwickler zu unübersichtlichen try-catch-Kaskaden.

Dieser Leitfaden stellt das Pragmatic Payload-Driven API-Design vor – eine praxiserprobte Hybridarchitektur, die Klarheit und Entwicklerfreundlichkeit maximiert.

🏛️ Kernphilosophie: Trennung von Infrastruktur und Business-Logik

Die goldene Regel lautet:

• HTTP Status Code: Signalisiert ausschließlich den Zustand von Datentransport und Infrastruktur (Routing, Gateway, Netzwerk, Schema-Validierung).
• Response Payload (JSON): Signalisiert das Ergebnis von Geschäftsregeln und Domänenlogik.

Solange der Request das API Gateway passiert, den Controller erreicht und die Applikation vollständig durchläuft (selbst wenn die Operation an einer Geschäftsbedingung wie unzureichendem Guthaben scheitert), gilt die Kommunikation als erfolgreich. Folglich wird stets mit 200 OK geantwortet.

📋 Standard-Envelope-Struktur

Jede API, die die Domänenlogik erreicht, antwortet mit folgender konsistenter JSON-Struktur:

{
  "success": true,               // boolean: Zeigt an, ob die Geschäftslogik erfolgreich war
  "code": "SUCCESS",             // UPPERCASE Business-Code für clientseitige Bedingungen
  "message": "Operation success",// Nachricht für Entwickler oder zur direkten UI-Anzeige
  "data": { ... },               // Nutzdaten-Objekt, Array oder null
  "error": null                  // Fehlerdetails im Falle eines Fehlschlags
}

✨ Der gezielte Einsatz der 2xx-Statuscodes

Wir nutzen die 2xx-Familie sinnvoll, um Bandbreite zu sparen:

• 200 OK (Erfolg mit Nutzdaten): Für Standard-Abfragen (GET) und Ressourcenerstellung mit Rückgabedaten.
• 204 No Content (Erfolg ohne Body): Für Operationen, bei denen das Ergebnis feststeht (z. B. DELETE /users/123), ohne überflüssige Payload zu übertragen.
• 202 Accepted (Asynchroner Auftrag): Für rechenintensive Aufgaben (z. B. 1-Mio.-Zeilen-Export). Sendet sofort 202 mit jobId zurück, um Timeouts zu verhindern.

🛡️ Strikte Abgrenzung von 4xx und 5xx

4xx- und 5xx-Codes dürfen unter keinen Umständen für fachliche Fehler verwendet werden. Sie obliegen Framework, Gateway und Middleware:

• 400 Bad Request: Syntaxfehler im JSON, ungültige Schemavalidierung.
• 401 Unauthorized: Fehlender oder abgelaufener Access Token.
• 403 Forbidden: Authentifiziert, aber keine ausreichenden Rechte (RBAC).
• 404 Not Found: Bedeutet einzig und allein: „URL falsch oder Endpoint existiert nicht.“ (Niemals bei leerem DB-Ergebnis nutzen; dort 200 OK + data: null zurückgeben).
• 429 Too Many Requests: Rate-Limit überschritten.
• 500 Internal Server Error: Serverabsturz, Datenbankausfall oder unbehandelte Exceptions.

📊 API-Design-Aktionsmatrix

💻 Frontend-Integration: Axios-Interceptor-Muster

import axios from 'axios';

const api = axios.create({ baseURL: 'https://api.example.com/v1' });

// Globaler Interceptor für Netzwerk- und Gateway-Fehler
api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response) {
      const { status } = error.response;
      if (status === 401) window.location.href = '/login';
      else if (status === 403) alert('Zugriff verweigert');
      else if (status >= 500) alert('Serverfehler');
    }
    return Promise.reject(error);
  }
);

// Im Component: Keine try-catch-Verschachtelung mehr
async function handleTransfer(amount) {
  const res = await api.post('/transfer', { amount });
  if (!res.data.success) {
    if (res.data.code === 'NO_FUND') openTopUpModal();
    else alert(res.data.message);
    return;
  }
  alert('Überweisung erfolgreich!');
}

❓ Häufig gestellte Fragen (FAQ)

🏁 Fazit

Pragmatic Payload-Driven API-Design eliminiert typische Reibungsverluste zwischen Backend und Frontend. Klare Zuständigkeiten und standardisierte JSON-Umschläge führen zu wartbarem, hochgradig produktionsreifem Code.