คุณออกแบบ error response ที่สอดคล้องกันและรายงาน validation error อย่างไร?

Question

IT Interview Practice · Accepted Answer

error response ที่ดีทำสองอย่าง: ใช้ **HTTP status code ที่ถูกต้อง** (สัญญาณที่เครื่องอ่านได้) และคืน **body ที่มีโครงสร้างและสอดคล้องกัน** ที่นักพัฒนานำไปทำอะไรต่อได้ รูปร่างของ error ที่ไม่สอดคล้องกันเป็นหนึ่งในต้นตอความเจ็บปวดที่ใหญ่ที่สุดฝั่ง client

## ใช้รูปแบบ error มาตรฐาน: RFC 7807 (problem+json)

RFC 7807 นิยาม body "problem details" มาตรฐานพร้อม media type เฉพาะ ทำให้ทุก error ทั่วทั้ง API ของคุณดูเหมือนกัน:

```http
HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/not-found",
  "title": "Resource not found",
  "status": 404,
  "detail": "No user exists with id 999",
  "instance": "/users/999"
}
```

- `type` — URI ที่ระบุประเภทของ error (dereference ไปยังเอกสารได้)
- `title` — สรุปสั้น ๆ ที่มนุษย์อ่านได้ (คงที่ต่อแต่ละ `type`)
- `status` — HTTP status สะท้อนซ้ำมาไว้เพื่อความสะดวก
- `detail` — คำอธิบายเฉพาะสำหรับเหตุการณ์ *ครั้งนี้*
- `instance` — request/ทรัพยากรใดที่เกิดเหตุ

## validation error: รายงานทั้งหมดในคราวเดียว

สำหรับการ validate ฟอร์ม/ฟิลด์ ให้คืน `422` (หรือ `400`) และ **อาร์เรย์ของ error รายฟิลด์** เพื่อให้ client เน้นทุกฟิลด์ที่ผิดในรอบเดียว — ไม่ใช่ทีละ error:

```http
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation failed",
  "status": 422,
  "errors": [
    { "field": "email", "code": "invalid_format", "message": "must be a valid email" },
    { "field": "age",   "code": "out_of_range",   "message": "must be >= 18" }
  ]
}
```

## หลักการ

```text
✓ Same body shape for every error (one code path on the client)
✓ A stable machine-readable code (type/code) — clients branch on this, not on prose
✓ Human-readable message for developers/logs
✗ Never leak stack traces, SQL, or internal paths to clients
```

## ทำไมจึงสำคัญ

การออกแบบ error คือจุดที่ API เงียบ ๆ ประสบความสำเร็จหรือล้มเหลวในโลกจริง: happy path นั้นง่าย แต่ผู้ใช้ใช้เวลา debug ส่วนใหญ่ไปกับเส้นทาง error และสัญญา error ที่ไม่สอดคล้องหรือคลุมเครือทำให้การ integrate ทรมาน ผู้สัมภาษณ์ใช้ข้อนี้ตรวจสองอย่าง หนึ่ง **status code กับ body ที่มีโครงสร้างทำงานร่วมกัน** — status คือสัญญาณหยาบสำหรับเครื่องมือและการ retry ส่วน body พกรายละเอียดที่นำไปทำต่อได้ — ไม่ใช่ anti-pattern แบบ `200 OK` ที่มี error ซ่อนอยู่ข้างใน สอง **error code ที่เครื่องอ่านได้และคงที่** (ผ่าน `type` ของ RFC 7807 หรือฟิลด์ `code`) เพื่อให้ client แตกแขนงตาม `"insufficient_funds"` แทนการจับคู่สตริงข้อความภาษาอังกฤษที่อาจถูกเขียนใหม่หรือแปลภาษา การคืน validation error ทั้งหมดในคราวเดียว และไม่รั่วรายละเอียดภายในอย่าง stack trace ทำให้คำตอบสมบูรณ์และแสดงว่าคุณเคยสร้าง API ที่ทีมอื่นต้องใช้จริง

ใช้รูปแบบ error มาตรฐาน: RFC 7807 (problem+json)

validation error: รายงานทั้งหมดในคราวเดียว

หลักการ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง