तपाईं कसरी एकरूप error response design गर्नुहुन्छ र validation error हरू रिपोर्ट गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

एउटा राम्रो error response ले दुई कुरा गर्छ: यसले **सही HTTP status code** (मेसिन-पठनीय सङ्केत) प्रयोग गर्छ, र यसले एउटा **एकरूप, संरचित body** फर्काउँछ जसमा developer ले कार्य गर्न सक्छ। असंगत error आकार client-पक्षको पीडाका सबैभन्दा ठूला स्रोतमध्ये एक हो।

## एउटा 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 (doc मा dereference गर्न मिल्ने)।
- `title` — छोटो, मानव-पठनीय सारांश (प्रति `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 सम्झौताले integration दुखदायी बनाउँछ। Interviewer हरूले यसलाई दुई कुरा जाँच्न प्रयोग गर्छन्। पहिलो, **status code र संरचित body सँगै काम गर्दै** — status tooling र retry का लागि खस्रो सङ्केत हो, body ले कार्ययोग्य विवरण बोक्छ — भित्र error सहितको `200 OK` को anti-pattern होइन। दोस्रो, एउटा **स्थिर, मेसिन-पठनीय error code** (RFC 7807 को `type` वा एउटा `code` field मार्फत) ताकि client ले पुनः-शब्द वा localize हुन सक्ने अंग्रेजी message string-match गर्नुको सट्टा `"insufficient_funds"` मा branch गर्न सकोस्। सबै validation error एकैचोटि फर्काउनु, र stack trace जस्ता आन्तरिक विवरण कहिल्यै leak नगर्नु, ले तपाईंले अन्य team ले वास्तवमा प्रयोग गर्नुपरेका API बनाउनुभएको छ भन्ने देखाउने जवाफ पूरा गर्छ।

एउटा standard error format प्रयोग गर्नुहोस्: RFC 7807 (problem+json)

Validation error हरू: सबै एकैचोटि रिपोर्ट गर्नुहोस्

सिद्धान्तहरू

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू