Error Responses: Problem Details

Errors अनुबंध का हिस्सा हैं

Clients को विफलताएँ सँभालनी होती हैं, इसलिए हर error को एक-सा आकार दें। एक मानक है Problem Details for HTTP APIs (RFC 9457, जो RFC 7807 की जगह लेता है), media type application/problem+json, जिसमें members type (error की क़िस्म बताने वाला URI), title, status, detail और वैकल्पिक विस्तार, जैसे field-स्तर validation के लिए errors सूची। संदेश कार्रवाई योग्य रखें (बताएँ क्या बदलना है), स्थिर मशीन-पठनीय type या code मान रखें जिन पर clients switch कर सकें, support के लिए request ID शामिल करें, और stack traces, SQL या file paths जैसी अंदरूनी जानकारी कभी लीक न करें।

problem+json response, चलाकर

मैंने यह केवल Python standard library से बने छोटे असली HTTP API पर चलाया (पूरा कोड केस स्टडी में)। न मौजूद item माँगने पर 404 मिलता है, content type application/problem+json और मानक members के साथ।

# uses srv, base and call() from the runnable demo in the case study
s, h, b = call("GET", "/v2/items/99"); print(s, h["Content-Type"], b)

Output:

404 application/problem+json {'type': 'about:blank', 'title': 'Not Found', 'status': 404, 'detail': 'Item 99 does not exist.'}

Field विवरण वाला validation error

errors विस्तार हर अमान्य field की सूची देता है ताकि UI उसे चिह्नित कर सके। (demo API का आकार, JSON के रूप में।)

{
  "type": "https://api.example.com/problems/validation",
  "title": "Validation failed",
  "status": 422,
  "detail": "amount must be positive.",
  "errors": [{"field": "amount", "message": "must be > 0"}],
  "request_id": "req_8f3a21"
}

त्वरित जाँच: हर error को एक-सा JSON आकार क्यों दें?

• JSON इसे ज़रूरी करता है
• यह status code छिपाता है
• यह डिज़ाइन से responses लंबे करता है
• Clients सभी विफलताएँ एक parser और तर्क से सँभाल सकते हैं