OpenAPI Breaking Changes มีอะไรบ้าง และกันยังไงก่อนขึ้น production

หลายทีมเริ่มใช้ OpenAPI ด้วยเหตุผลที่ดี เช่นอยากมี contract กลางระหว่าง frontend, backend และ integrations ภายนอก อยากให้เอกสาร API ชัดขึ้น หรืออยากใช้ schema ไปช่วยเรื่อง validation และ code generation แต่พอระบบเริ่มโตขึ้น คำถามที่สำคัญกว่าจะตามมาเสมอ

อะไรถือเป็น breaking change จริง
เปลี่ยน field แค่นิดเดียวทำไม client พัง
เพิ่ม enum value ถือว่า break ไหม
ลบ field ที่คิดว่าไม่มีใครใช้แล้วได้หรือยัง
จะรู้ได้อย่างไรว่าสิ่งที่กำลังเปลี่ยนกระทบคนอื่นหรือไม่
ควรจับเรื่องพวกนี้ตรงไหน ก่อน merge หรือก่อน deploy

ปัญหานี้สำคัญมาก เพราะการเปลี่ยน contract ของ API ไม่เหมือนการ refactor ภายในระบบ ต่อให้ backend compile ผ่าน ต่อให้ unit test ผ่าน ต่อให้ทีมที่แก้รู้สึกว่า “เปลี่ยนแค่นิดเดียว” ก็ยังอาจทำให้ frontend, mobile app, partner integration, worker ภายใน หรือ data pipeline พังได้ทันที

บทความนี้อธิบายว่า breaking changes ใน OpenAPI มีอะไรบ้าง อะไรคือจุดที่คนมักประเมินต่ำเกินไป และควรตั้งกระบวนการกันปัญหาอย่างไรก่อนขึ้น production

TL;DR

สรุปให้สั้นที่สุด

breaking change คือการเปลี่ยน contract ที่ทำให้ client เดิมใช้งานไม่ได้ตามข้อตกลงเดิม

สิ่งที่อันตรายคือ breaking changes จำนวนมากไม่ได้ดูใหญ่โต เช่น

ลบ field
เปลี่ยน type
เปลี่ยน enum
เปลี่ยน required/optional
เปลี่ยน error shape
เปลี่ยนความหมายของ field เดิม

ถ้าระบบของคุณใช้ OpenAPI จริง ควรมีอย่างน้อย

contract diff checks
validation discipline
release checklist
versioning policy
การคุยกับ stakeholder ก่อนเปลี่ยน contract สำคัญ

Breaking Change คืออะไรในโลกของ API

breaking change คือการเปลี่ยน API ที่ทำให้ consumer เดิมซึ่งเคยใช้งานได้ตาม contract เดิม ไม่สามารถทำงานได้เหมือนเดิมโดยไม่ต้องแก้ไขฝั่งตัวเอง

คำสำคัญคือ “consumer เดิม” และ “ไม่ต้องแก้ไข”

ถ้าคุณเปลี่ยนอะไรบางอย่างแล้ว client เก่าต้องแก้โค้ดใหม่ ต้องเปลี่ยน parsing logic ใหม่ ต้องรับมือ response ใหม่ หรือถึงขั้นเรียก endpoint เดิมไม่ได้อีกแล้ว นั่นมักถือเป็น breaking change

จุดที่ต้องระวังคือคำว่า break ไม่ได้แปลว่าระบบล่มทันทีเสมอไป บางครั้งมันเป็นการ break แบบเงียบ เช่น

ค่า field ยังมาอยู่ แต่ type เปลี่ยน
enum มีค่าใหม่แล้ว client parse ไม่ผ่าน
response code เปลี่ยน ทำให้ client workflow เปลี่ยน
field ยังอยู่แต่ semantics เปลี่ยนจน business logic ฝั่ง client เพี้ยน

ทำไม Breaking Changes ถึงถูกประเมินต่ำเกินไปบ่อย

สาเหตุหนึ่งคือทีม backend มักมองจากมุม implementation ภายใน เช่น

route ยังอยู่
endpoint ยังตอบได้
test ฝั่ง service ยังผ่าน
schema ใหม่ดู “สมเหตุสมผลกว่าเดิม”

แต่ consumer ไม่ได้เห็นภายใน เขาเห็นแค่สัญญาที่คุณเคยให้ไว้ ถ้าสัญญานั้นเปลี่ยนโดยไม่ประกาศหรือไม่รองรับย้อนหลัง สิ่งที่พังอาจไม่ใช่แค่ frontend ชุดเดียว แต่อาจรวมถึง

mobile app ที่ปล่อย version ใหม่ช้ากว่าเว็บ
partner integrations ที่ไม่ได้ sync กับคุณทุกสัปดาห์
internal tools ที่ไม่มี owner ชัดเจน
scripts หรือ cron jobs เก่า
analytics pipelines
queue consumers
generated SDKs

ยิ่งระบบมีหลาย consumer มากเท่าไร breaking change ยิ่งต้องถูกมองเป็นเรื่อง release discipline ไม่ใช่แค่เรื่อง schema

ตัวอย่าง Breaking Changes ที่เจอบ่อย

1) ลบ endpoint หรือเปลี่ยน path

เช่น

จาก POST /payments เป็น POST /payment-intents
จาก /customers/{id} เป็น /accounts/{id}

นี่เป็น breaking change ตรงตัว เพราะ client เดิมเรียก path เดิมแล้วจะใช้ไม่ได้ทันที

2) เปลี่ยน HTTP method

เช่น

จาก POST /orders/{id}/cancel เป็น PATCH /orders/{id}

แม้ความหมายทาง API อาจดูดีขึ้น แต่สำหรับ client เดิมนี่คือ break เต็มรูปแบบ

3) เปลี่ยน field จาก optional เป็น required

เช่นเดิม client ส่ง body แบบนี้ได้

{
  "amount": 100,
  "currency": "THB"
}

แต่เวอร์ชันใหม่บังคับ orderId เป็น required

{
  "amount": 100,
  "currency": "THB",
  "orderId": "ord_123"
}

client เดิมจะ fail ทันทีถ้าไม่ได้ส่ง field ใหม่

4) ลบ field ใน response

เช่นเดิม response มี

{
  "success": true,
  "paymentId": "pay_123",
  "status": "created"
}

แต่เวอร์ชันใหม่ลบ status ทิ้งเพราะคิดว่า redundant

ถ้า frontend หรือ integration เดิมยังใช้ field นี้อยู่ ก็จะพังได้ทันที

5) เปลี่ยน type ของ field

เช่น

เดิม amount เป็น number
ใหม่กลายเป็น string
เดิม createdAt เป็น ISO string
ใหม่กลายเป็น Unix timestamp

แม้ข้อมูลจะ “ยังมีอยู่” แต่ client ที่ parse ตามของเดิมอาจพังหรือทำงานผิดโดยไม่ชัดเจน

6) เปลี่ยน enum values

อันนี้ถูกมองข้ามบ่อยมาก

เช่นเดิม field status รับค่า

pending
approved
rejected

แล้วเพิ่ม review_required เข้ามา หรือเปลี่ยนชื่อ approved เป็น accepted

สำหรับบางระบบ นี่คือ breaking change ทันที เพราะ client อาจ switch-case ครบทุกค่าตามของเดิมไว้แล้ว

7) เปลี่ยนความหมายของ field เดิม

นี่เป็น break ที่อันตรายเพราะไม่เห็นชัดจาก schema เสมอไป

เช่น field amount เดิมหมายถึงยอดก่อนหักส่วนลด แต่ภายหลังทีมเปลี่ยนให้มันหมายถึงยอดสุทธิแทน ทั้งที่ชื่อ field ยังเหมือนเดิม

ต่อให้ schema ไม่เปลี่ยนเลย semantics ก็เปลี่ยน และ consumer อาจคำนวณผิดทันที

8) เปลี่ยน error response shape

หลายทีมสนใจแต่ success response แต่ลืมว่า client บางตัวพึ่งพา error structure เช่น

error.code
error.message
field
details

ถ้าเปลี่ยน error shape โดยไม่ระวัง client ฝั่ง UI, monitoring หรือ support tooling อาจพังได้เหมือนกัน

9) เปลี่ยน authentication หรือ required headers

เช่น route เดิมไม่ต้องส่ง Idempotency-Key แต่ภายหลังบังคับ
หรือเดิมใช้ Authorization: Bearer อย่างเดียว แต่เวอร์ชันใหม่บังคับ header เพิ่ม

กรณีนี้ก็เป็น breaking change ถ้า client เดิมใช้งานต่อไม่ได้

สิ่งที่ “อาจไม่ break” แต่ต้องระวัง

ไม่ใช่ทุกการเปลี่ยนแปลงจะเป็น breaking change เสมอไป แต่ก็ไม่ควรมองข้าม

ตัวอย่างเช่น

เพิ่ม optional field ใหม่ใน response
เพิ่ม endpoint ใหม่
เพิ่ม optional query parameter
เพิ่ม response field โดยไม่ลบของเดิม

โดยหลัก สิ่งเหล่านี้มัก backward compatible แต่ยังต้องระวัง client ที่เขียนแบบ strict เกินไป เช่น deserialize แล้ว reject unknown fields หรือทำ UI logic ที่ assume response shape ตายตัว

ดังนั้นคำว่า “non-breaking” ไม่ได้แปลว่า “ปลอดภัย 100%” มันแปลแค่ว่าในเชิง contract มาตรฐานแล้ว client เดิมควรไปต่อได้โดยไม่ต้องแก้

จุดที่คนมักพลาด: เพิ่ม enum value ถือว่า break ไหม

คำตอบในโลกจริงคือ “บ่อยครั้งใช่”

ในทางทฤษฎีหลายคนมองว่าการเพิ่ม enum value เป็น additive change แต่สำหรับ consumer ที่เขียน logic แบบปิดชุดค่า เช่น

switch (status) {
  case "pending":
  case "approved":
  case "rejected":
    ...
  default:
    throw new Error("Unknown status");
}

การเพิ่มค่ากลางใหม่อาจทำให้ client พังทันที หรืออย่างน้อยทำงานผิด

ดังนั้นถ้าฟิลด์นั้นเป็น enum ที่ consumer นำไปตัดสินใจจริง การเพิ่มค่าใหม่ควรถูกมองด้วยความระวังระดับใกล้เคียง breaking change และควรสื่อสารก่อนเสมอ

การเปลี่ยน response code ก็อาจ break ได้

สมมติ route เดิมสร้าง resource แล้วคืน 201 Created
เวอร์ชันใหม่เปลี่ยนเป็น 200 OK

หรือเดิม validation fail คืน 400 แต่ใหม่เปลี่ยนเป็น 422

ถ้า client พึ่งพา status code เพื่อทำ branching logic การเปลี่ยนแบบนี้ก็อาจ break ได้ แม้ body จะยังคล้ายเดิมก็ตาม

การเปลี่ยน field order ไม่ควร break แต่บางระบบก็ยังเจอปัญหา

ตามหลักแล้ว JSON object ไม่ควรขึ้นกับลำดับ field แต่ระบบจริงบางตัวมี consumer แปลก ๆ หรือ tooling ที่ไม่ robust พอ ทำให้เรื่องที่ไม่ควร break กลายเป็นปัญหาได้

จุดนี้ไม่ได้แปลว่าคุณต้องรองรับ behavior ผิด ๆ ตลอดไป แต่หมายความว่าก่อนเปลี่ยนอะไรใน contract สำคัญ ควรรู้ว่า consumer จริงของคุณแข็งแรงแค่ไหน

จะกัน Breaking Changes ยังไงก่อนขึ้น production

การกันปัญหาพวกนี้ต้องใช้ทั้งเครื่องมือและวินัยในการปล่อย

1) Treat OpenAPI as contract จริง ไม่ใช่แค่เอกสาร

ถ้า OpenAPI เป็นแค่ไฟล์ docs ที่ไม่มีใครตรวจ runtime ไม่มีใคร diff ตอน PR และไม่มีใครใช้ในการทดสอบ มันจะช่วยเรื่อง breaking changes ได้น้อยมาก

2) ทำ contract diff checks ใน CI

ทุกครั้งที่ schema เปลี่ยน ควรมีการเทียบกับ version ก่อนหน้า แล้วรายงานว่าอะไรเป็น breaking change บ้าง เช่น

ลบ path
ลบ operation
เพิ่ม required field
ลบ response field
เปลี่ยน type
เปลี่ยน enum
เปลี่ยน header requirements

จุดสำคัญคือให้สิ่งเหล่านี้โผล่ตั้งแต่ PR ไม่ใช่รู้ตอน consumer เริ่มพังใน production

3) มี policy ว่าอะไรเปลี่ยนได้โดยไม่ต้อง version และอะไรต้อง version

ถ้าทีมไม่มี policy นี้ ทุกการตัดสินใจจะขึ้นกับความรู้สึกของคนแก้ในวันนั้น

4) ผูกกับ release checklist

ต่อให้ contract diff เจอ breaking change แล้ว ถ้าไม่มีขั้นตอนถามต่อว่า

ใครได้รับผลกระทบ
สื่อสารหรือยัง
มี migration path หรือยัง
มี deprecation period หรือยัง
มี rollout plan หรือยัง

สุดท้ายก็ยังพังได้เหมือนเดิม

5) ใช้ request/response validation จริงใน runtime หรืออย่างน้อยใน test

ยิ่ง schema ถูกใช้งานจริงมากเท่าไร โอกาสที่ implementation จะ drift จาก contract จะยิ่งลดลง

ลำดับการตัดสินใจเมื่อเจอ Breaking Change

ถ้าคุณรู้แล้วว่าการเปลี่ยนนี้ break แน่ ควรถามต่อเป็นลำดับแบบนี้

จำเป็นต้องเปลี่ยนจริงไหม
ถ้าไม่เปลี่ยนตอนนี้ มีทางเพิ่มแบบ backward-compatible ก่อนได้ไหม
ถ้าต้องเปลี่ยนจริง มีช่วง deprecation ได้ไหม
ต้อง version ใหม่หรือไม่
ใครบ้างคือ consumer ที่ได้รับผลกระทบ
จะทดสอบ compatibility ยังไง
จะ rollout ยังไงถ้ามี consumer หลายกลุ่ม

จุดนี้สำคัญมาก เพราะหลาย breaking changes เกิดจากการรีบแก้ contract ให้ “สะอาดขึ้น” โดยไม่คิดว่ากำลังผลัก cost ไปให้ consumer

ตัวอย่างของการเปลี่ยนแบบปลอดภัยกว่า

สมมติเดิม response มี field ชื่อ status

{
  "paymentId": "pay_123",
  "status": "created"
}

ทีมอยากเปลี่ยนให้ใช้ชื่อ paymentStatus แทนเพื่อให้ชัดขึ้น

วิธีที่เสี่ยงคือเปลี่ยนตรง ๆ แล้วลบ status ทันที

วิธีที่ปลอดภัยกว่าคือ

เพิ่ม paymentStatus เข้ามาก่อน
คง status ไว้ช่วงหนึ่ง
ใส่ deprecation note ใน schema/documentation
ติดตามว่า consumer ย้ายครบหรือยัง
ค่อยลบใน version ถัดไปหรือหลัง deprecation window

แบบนี้ backend อาจแบกความไม่สวยช่วงสั้น ๆ แต่ช่วยลดความเสี่ยง production ได้มากกว่า

OpenAPI Validation ช่วยเรื่องนี้ยังไง

ถ้าระบบใช้ OpenAPI validation จริง จะเห็นปัญหาเร็วขึ้นมาก เพราะ schema ไม่ใช่แค่เอกสาร แต่เป็นสิ่งที่ runtime หรือ test ใช้ enforce

ตัวอย่างเช่น

ถ้าคุณลบ field required ใน response โดยไม่ตั้งใจ test response contract จะ fail
ถ้าคุณบังคับ field ใหม่ใน request schema client เก่าอาจ fail ใน staging ก่อน
ถ้าคุณเปลี่ยน enum runtime validation อาจช่วยชี้ให้เห็น behavior ใหม่ชัดขึ้น

ดังนั้น OpenAPI validation กับ breaking change management เป็นเรื่องเดียวกันมากกว่าที่หลายทีมคิด

API Versioning ควรเข้ามาตอนไหน

versioning ไม่ใช่คำตอบทุกอย่าง แต่เป็นเครื่องมือสำคัญเมื่อคุณต้องปล่อย change ที่ backward-compatible ทำไม่ได้หรือไม่คุ้มจะรักษาแล้ว

ตัวอย่างที่ควรพิจารณา version ใหม่ เช่น

เปลี่ยน model หลักของ resource
เปลี่ยน response shape อย่างมีนัยสำคัญ
เปลี่ยนความหมายของ field เดิม
เปลี่ยน auth contract
เปลี่ยน workflow หลักของ endpoint

แต่อย่าใช้ versioning เป็นข้ออ้างในการปล่อยของมั่ว เพราะต่อให้มี /v2 ถ้าไม่มี deprecation plan และ migration guidance consumer ก็ยังเจ็บเหมือนเดิม

Requirement ที่ไม่ชัดทำให้ Breaking Changes เกิดบ่อย

อีกจุดที่ถูกมองข้ามคือ breaking changes จำนวนไม่น้อยไม่ได้เกิดจาก backend careless อย่างเดียว แต่เกิดจาก requirement ที่ยังไม่นิ่งตั้งแต่ต้น เช่น

ยังไม่รู้จริงว่า field ไหนเป็น canonical
ยังไม่ชัดว่าฝั่งไหนเป็น owner ของ semantics
ยังไม่รู้ว่า consumer มีใครบ้าง
ยังไม่มี model กลางของ resource

พอระบบเดินไปสักพัก ทีมจึงเริ่ม “แก้ชื่อให้ถูก” หรือ “เปลี่ยน response ให้ตรง business จริง” ซึ่งบ่อยครั้งกลายเป็น breaking change ที่หลีกเลี่ยงยาก

ตัวอย่าง OpenAPI ก่อนและหลังที่ break

ก่อน

paths:
  /payments:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - amount
                - currency
              properties:
                amount:
                  type: number
                currency:
                  type: string
      responses:
        "201":
          description: Payment created
          content:
            application/json:
              schema:
                type: object
                required:
                  - paymentId
                  - status
                properties:
                  paymentId:
                    type: string
                  status:
                    type: string

หลังแบบที่ break

paths:
  /payments:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - amount
                - currency
                - orderId
              properties:
                amount:
                  type: string
                currency:
                  type: string
                orderId:
                  type: string
      responses:
        "200":
          description: Payment created
          content:
            application/json:
              schema:
                type: object
                required:
                  - paymentId
                  - paymentStatus
                properties:
                  paymentId:
                    type: string
                  paymentStatus:
                    type: string

สิ่งที่ break ในตัวอย่างนี้มีหลายจุดพร้อมกัน

เพิ่ม orderId เป็น required
เปลี่ยน amount จาก number เป็น string
เปลี่ยน status code จาก 201 เป็น 200
ลบ status
เพิ่ม paymentStatus แทน

ต่อให้ทีม backend มองว่า schema ใหม่ “ชัดกว่า” แต่ consumer เดิมจะเจ็บทันที

ตัวอย่าง Express/Node.js สำหรับ contract-aware release guard

ตัวอย่างนี้ไม่ได้ทำ diff OpenAPI เต็มรูปแบบ แต่สื่อแนวคิดว่าควรมีชั้นตรวจ contract ใน pipeline ไม่ใช่ปล่อยให้ schema เปลี่ยนเงียบ ๆ

const fs = require("fs");

function loadJson(filePath) {
  return JSON.parse(fs.readFileSync(filePath, "utf8"));
}

function assertNoRemovedPaths(previousSpec, nextSpec) {
  const previousPaths = Object.keys(previousSpec.paths || {});
  const nextPaths = new Set(Object.keys(nextSpec.paths || {}));

  for (const path of previousPaths) {
    if (!nextPaths.has(path)) {
      throw new Error(`Breaking change detected: removed path ${path}`);
    }
  }
}

function assertNoRemovedResponseFields(previousSchema, nextSchema, path, method, statusCode) {
  const prevProps =
    previousSchema?.paths?.[path]?.[method]?.responses?.[statusCode]?.content?.["application/json"]?.schema?.properties || {};

  const nextProps =
    nextSchema?.paths?.[path]?.[method]?.responses?.[statusCode]?.content?.["application/json"]?.schema?.properties || {};

  for (const field of Object.keys(prevProps)) {
    if (!(field in nextProps)) {
      throw new Error(
        `Breaking change detected: removed response field ${field} from ${method.toUpperCase()} ${path} ${statusCode}`
      );
    }
  }
}

function main() {
  const previousSpec = loadJson("./openapi.previous.json");
  const nextSpec = loadJson("./openapi.next.json");

  assertNoRemovedPaths(previousSpec, nextSpec);
  assertNoRemovedResponseFields(previousSpec, nextSpec, "/payments", "post", "201");

  console.log("Basic contract checks passed");
}

main();

โค้ดนี้ยังง่ายมากและไม่ครอบคลุมของจริง แต่ประเด็นสำคัญคือ breaking changes ควรถูกจับใน pipeline ก่อน deploy ไม่ใช่รอให้ consumer พบเอง

จุดที่ต้องระวังใน production

1) อย่าคิดว่า “ไม่มีใครใช้อยู่แล้ว” ถ้ายังไม่มีหลักฐาน

field หรือ endpoint ที่ดูเหมือนไม่มีใครใช้ อาจยังถูกเรียกจาก mobile version เก่า, cron job, partner หรือ script ภายใน

2) อย่าดูแค่ success response

error contract, headers, status code และ auth requirements ก็ break ได้เหมือนกัน

3) อย่าพึ่ง version ใหม่ทันทีทุกครั้ง

บางการเปลี่ยนสามารถเพิ่มแบบ backward-compatible ก่อนได้ และนั่นมักคุ้มกว่าการแตก version ใหม่เร็วเกินไป

4) อย่าปล่อย schema drift ระหว่าง doc กับ runtime

ถ้า docs, validation และ implementation ไม่ตรงกัน คุณจะไม่มีแหล่งจริงให้เชื่อถือได้ตอนตรวจ break

5) อย่ามอง breaking changes เป็นเรื่องเทคนิคอย่างเดียว

หลายครั้งมันเป็นเรื่อง product contract และ stakeholder management พอ ๆ กับเรื่อง code

รีวิวแนวทางนี้แบบ production-minded

Correctness

การมอง OpenAPI เป็น contract จริงจะช่วยให้ทีมเห็นผลกระทบของการเปลี่ยนแปลงตั้งแต่ต้น ไม่ใช่ดูแค่ว่า service ยังทำงานได้

Security

บาง breaking changes กระทบเรื่อง security โดยตรง เช่นเปลี่ยน auth flow, required headers หรือ response ที่เผลอ expose field ใหม่ ดังนั้น contract review จึงช่วยลดความเสี่ยงหลุดข้อมูลและ misconfiguration ได้ด้วย

Efficiency

การมี diff checks และ release discipline ช่วยลดต้นทุนการแก้ย้อนหลัง เพราะปัญหา contract แตกมักแพงกว่าการแก้ logic ภายในระบบมาก

Error handling

ถ้าทีมรู้ล่วงหน้าว่าอะไรเป็น breaking change จะวาง deprecation, fallback และ migration path ได้ดีขึ้น แทนที่จะปล่อยให้ error ไปโผล่ที่ consumer โดยไม่มีบริบท

Checklist สั้น ๆ ก่อนปล่อย OpenAPI change ขึ้น production

ตรวจว่ามี path, method หรือ operation ไหนถูกลบหรือเปลี่ยนหรือไม่
ตรวจว่ามี required fields ใหม่หรือไม่
ตรวจว่ามี field ไหนถูกลบหรือเปลี่ยน type หรือไม่
ตรวจ enum values และ response codes
ตรวจ error response shape และ required headers
มี contract diff checks ใน CI
route สำคัญมี validation หรือ tests ผูกกับ schema
ถ้าเป็น breaking change มี migration path หรือ deprecation plan
ถ้าจำเป็นต้อง break จริง มี versioning strategy ชัดเจน
release checklist และ stakeholder communication พร้อมก่อน deploy

บทความที่ควรอ่านต่อ

สรุป

breaking changes ใน OpenAPI ไม่ได้อันตรายเพราะมันซับซ้อนมากเสมอไป แต่อันตรายเพราะมันดูเล็กเกินกว่าจะถูกระวัง ทั้งที่จริงแล้วมันคือการเปลี่ยนสัญญาที่ consumer พึ่งพาอยู่

ถ้าทีมของคุณใช้ OpenAPI จริง ควรมองเรื่องนี้เป็นส่วนหนึ่งของ release governance ไม่ใช่แค่ schema hygiene แล้วจัดการมันด้วย contract checks, validation, versioning และ communication ที่เหมาะสม

สรุปสั้นที่สุดคือ

backend เปลี่ยน implementation ได้บ่อย แต่ contract ของ API ไม่ควรถูกเปลี่ยนแบบไม่ตั้งใจ