আপনি কীভাবে সামঞ্জস্যপূর্ণ error response design করেন এবং validation error রিপোর্ট করেন?

Question

IT Interview Practice · Accepted Answer

একটি ভালো error response দুটি কাজ করে: এটি **সঠিক HTTP status code** ব্যবহার করে (machine-readable সংকেত), এবং একটি **সামঞ্জস্যপূর্ণ, structured body** ফেরত দেয় যার ওপর একজন developer কাজ করতে পারে। অসামঞ্জস্যপূর্ণ error আকৃতি client-side ব্যথার সবচেয়ে বড় উৎসগুলোর একটি।

## একটি standard error format ব্যবহার করুন: RFC 7807 (problem+json)

RFC 7807 একটি নিবেদিত media type সহ একটি standard "problem details" body সংজ্ঞায়িত করে, তাই আপনার API জুড়ে প্রতিটি error একই রকম দেখায়:

```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` — error শ্রেণি শনাক্ত করা একটি URI (docs-এ dereference করা যায়)।
- `title` — একটি সংক্ষিপ্ত, human-readable সারসংক্ষেপ (প্রতি `type`-এ স্থিতিশীল)।
- `status` — HTTP status, সুবিধার জন্য প্রতিফলিত।
- `detail` — *এই* ঘটনার জন্য একটি সুনির্দিষ্ট ব্যাখ্যা।
- `instance` — কোন request/resource-এ এটি ঘটেছে।

## Validation error: সব একসাথে রিপোর্ট করুন

Form/field validation-এর জন্য, `422` (বা `400`) এবং একটি **field error-এর array** ফেরত দিন যাতে client এক পাসে প্রতিটি খারাপ field হাইলাইট করতে পারে — একবারে একটি 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 design হলো যেখানে API বাস্তব দুনিয়ায় নীরবে সফল বা ব্যর্থ হয়: happy path সহজ, কিন্তু consumer-রা তাদের debugging-এর বেশিরভাগ সময় error path-এ কাটায়, এবং একটি অসামঞ্জস্যপূর্ণ বা অস্পষ্ট error contract integration-কে দুর্বিষহ করে। Interviewer-রা এটি দুটি জিনিস যাচাই করতে ব্যবহার করেন। প্রথমত, **status code এবং structured body একসাথে কাজ করা** — status হলো tooling ও retry-র জন্য মোটা সংকেত, body actionable বিশদ বহন করে — একটি error ভিতরে থাকা `200 OK`-এর anti-pattern নয়। দ্বিতীয়ত, একটি **স্থিতিশীল, machine-readable error code** (RFC 7807-এর `type` বা একটি `code` field দিয়ে) যাতে client একটি English message-এ string-match করার বদলে `"insufficient_funds"`-এ branch করতে পারে, যা পুনরায় লেখা বা localize হতে পারে। সব validation error একসাথে ফেরত দেওয়া, এবং stack trace-এর মতো অভ্যন্তরীণ বিশদ কখনো leak না করা, এমন একটি উত্তর পূর্ণ করে যা দেখায় আপনি এমন API বানিয়েছেন যা অন্য দল সত্যিই ব্যবহার করতে বাধ্য হয়েছে।

একটি standard error format ব্যবহার করুন: RFC 7807 (problem+json)

Validation error: সব একসাথে রিপোর্ট করুন

নীতিমালা

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন