HTTP স্ট্যাটাস কোড

একটি সম্পূর্ণ, অনুসন্ধানযোগ্য HTTP স্ট্যাটাস কোড রেফারেন্স

এই HTTP স্ট্যাটাস কোড রেফারেন্স প্রতিটি স্ট্যান্ডার্ড কোড একটি অনুসন্ধানযোগ্য জায়গায় রাখে। 404-এর মতো একটি সংখ্যা, unauthorized-এর মতো একটি নাম, বা redirect-এর মতো একটি কীওয়ার্ড টাইপ করুন, আর মিলে যাওয়া কোডগুলো সহজ ভাষার অর্থসহ সঙ্গে সঙ্গে দেখা যায়। প্রতিটি এন্ট্রিতে এর ক্লাস রঙ, অফিসিয়াল RFC রেফারেন্স, এবং — এরর হলে — সাধারণ কারণ ও সমাধান দেখানো থাকে।

স্ট্যাটিক HTTP স্ট্যাটাস কোডের তালিকার পেজের বিপরীতে, এটি ইন্টারঅ্যাকটিভ: ক্লাস দিয়ে ফিল্টার করুন, একটি কম্প্যাক্ট চিট শিটে পাল্টান, বা সরাসরি একটি একক কোডে যান। যেহেতু পুরো ডেটাসেট পেজের সাথেই আসে, লুকআপ তাৎক্ষণিক এবং অফলাইনে কাজ করে। কোনো সাইনআপ নেই, কোনো রেট লিমিট নেই, উত্তর দেখার আগে কোনো বিজ্ঞাপন লোড হয় না।

HTTP স্ট্যাটাস কোডের পাঁচটি ক্লাস

প্রতিটি কোড তার প্রথম অঙ্ক দিয়ে নির্ধারিত পাঁচটি ক্লাসের একটিতে পড়ে। 1xx Informational মানে রিকোয়েস্ট গৃহীত হয়েছে এবং চলছে (100 Continue, 101 Switching Protocols)। 2xx Success মানে এটি কাজ করেছে (200 OK, 201 Created, 204 No Content)। 3xx Redirection আপনাকে অন্য কোথাও পাঠায় (301, 302, 304, 307, 308)।

4xx Client error মানে আপনার রিকোয়েস্ট ভুল (400, 401, 403, 404, 429), এবং 5xx Server error মানে সার্ভার ব্যর্থ হয়েছে (500, 502, 503, 504)। ক্লাসটি জানা লগে ডুব দেওয়ার আগেই কার দোষ তা বলে দেয়: একটি 4xx আপনার ঠিক করার বিষয়, একটি 5xx সার্ভারের। HTTP এরর হ্যান্ডলিং সম্পর্কে জানার সবচেয়ে উপযোগী একক পার্থক্য এটাই — এটি আপনাকে বলে দেয় কোথায় দেখা শুরু করবেন।

সবচেয়ে সাধারণ HTTP স্ট্যাটাস কোড এবং তাদের অর্থ

কয়েকটি কোড ওয়েব তৈরি বা ডিবাগ করার সময় আপনি যা দেখবেন তার প্রায় সবকিছু কভার করে। সাফল্যের দিকে, 200 OK এবং 201 Created নিশ্চিত করে রিকোয়েস্ট কাজ করেছে। রিডাইরেক্টের মধ্যে, 301 (স্থায়ী) এবং 302 (অস্থায়ী) প্রধান জোড়া, ব্রাউজার ক্যাশিং চালানো 304 Not Modified-সহ।

client errors-এর মধ্যে, 400, 401, 403, 404 এবং 429 প্রাধান্য পায়; server errors-এর মধ্যে, 500, 502, 503 এবং 504। সম্পূর্ণ রেজিস্ট্রিকে এই গুরুত্বপূর্ণ সংক্ষিপ্ত তালিকায় ফিল্টার করতে ওপরে 'Common only' টগল করুন, প্রতিটির জন্য কারণ ও সমাধানসহ।

4xx বনাম 5xx: ক্লায়েন্ট এরর বনাম সার্ভার এরর

4xx এবং 5xx এরর-এর পার্থক্য আপনাকে বলে দেয় কোথায় দেখতে হবে। একটি 4xx একটি ক্লায়েন্ট এরর — রিকোয়েস্টটি বিকৃত, অথেন্টিকেটেড নয়, নিষিদ্ধ, বা একটি অনুপস্থিত রিসোর্সের দিকে নির্দেশিত — তাই এটি অপরিবর্তিত পাঠালে সাহায্য হবে না। রেসপন্স বডি ও হেডার পড়ুন, রিকোয়েস্ট ঠিক করুন, তারপর আবার চেষ্টা করুন।

একটি 5xx একটি সার্ভার এরর — আপনার রিকোয়েস্ট হয়তো পুরোপুরি বৈধ কিন্তু সার্ভার এটি পূরণ করতে পারেনি। একটি 500 সাধারণত একটি অহ্যান্ডলড এক্সসেপশন বোঝায়, একটি 502 মানে প্রক্সির পেছনে একটি মৃত আপস্ট্রিম, এবং একটি 503 মানে সাময়িক ওভারলোড বা মেইনটেন্যান্স। 5xx-এর জন্য, সমাধান আপনার রিকোয়েস্টে নয়, সার্ভার লগে থাকে। এর মানে হলো রিট্রাই লজিক শুধু 5xx রেসপন্সে প্রয়োগ করা উচিত, এক্সপোনেনশিয়াল ব্যাকঅফসহ — একটি 4xx আবার চেষ্টা করা কোনো সুবিধা ছাড়াই শুধু রিকোয়েস্ট কোটা পোড়ায়।

Cloudflare 5xx কোড (520–530) যা স্পেকে পাবেন না

আপনার সাইট Cloudflare-এর পেছনে থাকলে, আপনি অফিসিয়াল HTTP স্পেক কখনও সংজ্ঞায়িত না করা নন-স্ট্যান্ডার্ড 5xx কোড-এর একটি পরিবারের সাথে দেখা করবেন। 520 মানে অরিজিন একটি খালি বা অপ্রত্যাশিত রেসপন্স ফিরিয়েছে, 521 মানে অরিজিন কানেকশন প্রত্যাখ্যান করেছে (এটি অফলাইন বা Cloudflare-এর IP ফায়ারওয়াল করছে), 522 একটি TCP কানেকশন টাইমআউট, 523 মানে অরিজিন অ্যাক্সেসযোগ্য নয় (প্রায়ই খারাপ DNS), এবং 524 মানে অরিজিন সংযুক্ত হয়েছিল কিন্তু Cloudflare-এর ১০০-সেকেন্ড উইন্ডোর মধ্যে সাড়া দেয়নি।

SSL গ্রুপ — 525 SSL Handshake Failed এবং 526 Invalid SSL Certificate — দেখা যায় যখন আপনার অরিজিনের সার্টিফিকেট অনুপস্থিত, মেয়াদোত্তীর্ণ, বা Cloudflare-এর Full (Strict) মোডের সাথে মেলে না। 530 প্রায় সবসময় বডিতে একটি 1xxx এররসহ ভ্রমণ করে, সাধারণত একটি অরিজিন DNS ব্যর্থতা (Error 1016)। বেশিরভাগ রেফারেন্স সাইট এই কোডগুলো সম্পূর্ণভাবে বাদ দেয়, ঠিক যে কারণে ডেভেলপাররা কোনো ইনসিডেন্টের মাঝখানে এগুলো খুঁজতে থাকেন — এখানে সেগুলো স্ট্যান্ডার্ড কোডের মতোই কারণ-ও-সমাধান চিকিৎসাসহ অনুসন্ধানযোগ্য।

এটি MDN, httpstatuses.com এবং অন্যান্য রেফারেন্সের সাথে কীভাবে তুলনীয়

HTTP স্ট্যাটাস কোড লুকআপের জন্য সবচেয়ে বেশি ব্যবহৃত বিকল্প MDN Web Docs। MDN-এর কভারেজ সুবিস্তৃত ও প্রামাণিক, কিন্তু আপনি প্রতিটি কোডের জন্য একটি করে পেজ নেভিগেট করেন — একবারে সব কোড ফিল্টার করার কোনো সার্চ বার নেই, কোনো ক্লাস ফিল্টার নেই, কোনো কম্প্যাক্ট চিট-শিট মোড নেই। আপনি যদি ইতিমধ্যে জানেন যে আপনি একটি 429 দেখছেন এবং এর স্পেক সংজ্ঞা চান, MDN চমৎকার। আপনি আগে কখনও দেখেননি এমন একটি সংখ্যা ডিবাগ করলে, একটি অনুসন্ধানযোগ্য রেফারেন্স দ্রুততর।

httpstatuses.com একটি রঙ-কোডেড গ্রিডে কোড দেখায় সংক্ষিপ্ত বর্ণনাসহ কিন্তু সাধারণ কারণ বা এরর ঠিক করার উপায় ব্যাখ্যা করে না। restapitutorial.com ও w3schools দুটোই ফিল্টারিং ছাড়া স্ট্যাটিক টেবিলে HTTP কোড কভার করে। HTTP.cat একটি মজার মিম সাইট (প্রতিটি কোড একটি বিড়ালের ছবির সাথে ম্যাপ করা) কিন্তু বাস্তব ডিবাগিংয়ের জন্য অকার্যকর। এই টুল লাইভ সার্চ, ক্লাস ফিল্টার, চিট-শিট মোড, কারণ, সমাধান, Cloudflare 5xx কোড এবং RFC লিংক মিলিয়ে দেয় — সব একটি পেজে যা বিজ্ঞাপন ছাড়া অফলাইনে চলে।

HTTP স্ট্যাটাস কোড এবং SEO

স্ট্যাটাস কোড নীরবে নির্ধারণ করে সার্চ ইঞ্জিন একটি সাইট কীভাবে ক্রল ও র‍্যাঙ্ক করে। আপনি ইনডেক্স করাতে চান এমন প্রতিটি পেজ 200 OK ফেরত দেওয়া উচিত। আপনি একটি URL স্থায়ীভাবে পাল্টালে, একটি 301 Moved Permanently ব্যবহার করুন যাতে র‍্যাঙ্কিং সিগন্যাল সেটি অনুসরণ করে; শুধু অস্থায়ী পরিবর্তনের জন্য 302 ব্যবহার করুন যাতে মূল URL এর কর্তৃত্ব ধরে রাখে।

সরানো কনটেন্টের জন্য, 404 Not Found ও 410 Gone দুটোই একটি পেজকে ইনডেক্স থেকে বাদ দেয় — 410 দ্রুততর, কারণ এটি প্রতিশ্রুতি দেয় যে রিসোর্সটি স্থায়ীভাবে চলে গেছে। পরিকল্পিত ডাউনটাইমের সময়, একটি Retry-After হেডারসহ 503 Service Unavailable ফেরত দিন যাতে ক্রলাররা পরে ফিরে আসে ডি-ইনডেক্স করার বদলে। সাইট মাইগ্রেশনের সময় এই কোডগুলো ঠিক করা সবচেয়ে সস্তা জয়গুলোর একটি — এটি কনফিগার করতে মিনিট সময় লাগে, এবং SEO প্রভাব তাৎক্ষণিক।

গভীরে 1xx, 2xx ও 3xx কোড: সম্পূর্ণ সাফল্য ও রিডাইরেক্ট চিত্র

1xx Informational ক্লাসটি HTTP প্রোটোকল নিজের সাথে কথা বলছে। 100 Continue ব্যান্ডউইথ অপচয় এড়াতে বিদ্যমান: একজন ক্লায়েন্ট একটি বড় রিকোয়েস্ট বডি পাঠাতে চাইলে, প্রথমে সে Expect: 100-continue হেডারসহ শুধু হেডার পাঠায়; সার্ভার পেলোড গ্রহণ করতে ইচ্ছুক হলে 100 দিয়ে জবাব দেয়, বা বডি আসার আগেই একটি 4xx এরর দিয়ে প্রত্যাখ্যান করে। 101 Switching Protocols হলো হ্যান্ডশেক যা WebSocket কানেকশন চালায় — ব্রাউজার একটি Upgrade: websocket হেডার পাঠায়, এবং 101 নিশ্চিত করে সার্ভার সেই একই TCP কানেকশনে HTTP থেকে WebSocket প্রোটোকলে পাল্টাচ্ছে। আপনি খুব কমই এমন কোড লিখবেন যা 1xx কোড তৈরি করে, কিন্তু এগুলো বোঝা ব্যাখ্যা করে কেন আপনার WebSocket লাইব্রেরি এভাবে কাজ করে।

2xx Success ক্লাসের মধ্যে, কোডগুলো সাফল্যের বিভিন্ন আকার যোগাযোগ করে। 200 OK সবচেয়ে বিস্তৃত সাফল্য — একটি GET-এর জন্য এটি রিসোর্স ফিরিয়ে দেয়, একটি POST-এর জন্য এটি অ্যাকশনটি যা তৈরি করেছে তা ফিরিয়ে দেয়। 201 Created সংকীর্ণ: এটি সংকেত দেয় যে একটি POST বা PUT বিশেষভাবে একটি নতুন রিসোর্স তৈরি করেছে, এবং সার্ভারের একটি Location হেডার অন্তর্ভুক্ত করা উচিত সেটির দিকে নির্দেশ করে (যেমন, Location: /users/42)। 204 No Content মানে সাফল্য কিন্তু ইচ্ছাকৃতভাবে কোনো রেসপন্স বডি নেই — একটি DELETE এন্ডপয়েন্ট বা একটি PUT আপডেটের জন্য সঠিক পছন্দ যেখানে ক্লায়েন্টের ফলাফল দেখার দরকার নেই। 206 Partial Content মিডিয়া স্ট্রিমিং ও পুনরায়-শুরু-করা যায় এমন ডাউনলোডের মেরুদণ্ড: একজন ক্লায়েন্ট Range: bytes=0-1048575 হেডার পাঠালে, সার্ভার শুধু ফাইলের সেই অংশসহ 206 দিয়ে জবাব দেয়, যা ভিডিও প্লেয়ারদের শুরু থেকে ডাউনলোড না করেই সিক করতে দেয়।

3xx Redirection কোডগুলো ক্লায়েন্টদের কোথায় যেতে হবে তা বলার একটি নিখুঁত শব্দভাণ্ডার তৈরি করে। 301 Moved Permanently ও 308 Permanent Redirect দুটোই একটি চিরস্থায়ী মুভ সংকেত দেয়; পার্থক্যটি হলো 301 ঐতিহাসিকভাবে ব্রাউজারদের নতুন URL-এ একটি POST-কে GET-এ ডাউনগ্রেড করতে দিত, যখন 308 নিশ্চিত করে মূল মেথড সংরক্ষিত থাকে। একইভাবে, 302 Found ও 307 Temporary Redirect দুটোই একটি অস্থায়ী মুভ সংকেত দেয়, কিন্তু 307 মেথড লক করে রাখে। বাস্তবে: পেজ URL পরিবর্তনের জন্য 301 ব্যবহার করুন, একটি ফর্মের POST টার্গেট স্থায়ীভাবে রিডাইরেক্ট করার সময় 308 ব্যবহার করুন। 304 Not Modified প্রকৃতপক্ষে একটি রিডাইরেক্ট নয় — এটি একটি ক্যাশ ভ্যালিডেশন রিকোয়েস্টের সময় ব্রাউজারকে সার্ভারের বলা যে তার ক্যাশ করা কপি এখনও বর্তমান, তাই কোনো বডি পাঠানো হয় না, ব্যান্ডউইথ বাঁচায়। একটি ব্রাউজার একটি If-None-Match বা If-Modified-Since হেডার পাঠায়; রিসোর্স অপরিবর্তিত থাকলে, সার্ভার 304 দিয়ে জবাব দেয় এবং ব্রাউজার তার স্থানীয় ক্যাশ থেকে সার্ভ করে।

প্রতিটি ডেভেলপারের জানা উচিত সবচেয়ে গুরুত্বপূর্ণ 4xx ও 5xx কোড

4xx client error ক্লাসের মধ্যে, বেশ কয়েকটি কোড ধারাবাহিকভাবে ভুল ব্যবহৃত বা ভুল বোঝা হয়। 400 Bad Request সঠিক রেসপন্স যখন রিকোয়েস্ট সিনট্যাক্টিক্যালি বিকৃত — অবৈধ JSON, একটি অনুপস্থিত প্রয়োজনীয় কোয়েরি প্যারামিটার, বা ভুল ডেটা টাইপের একটি ফিল্ড। 401 Unauthorized খারাপভাবে নামকরণ করা: এটি প্রকৃতপক্ষে unauthenticated বোঝায়। রিকোয়েস্টে বৈধ ক্রেডেনশিয়াল নেই, এবং সার্ভারের কীভাবে অথেন্টিকেট করতে হবে তা বর্ণনা করে একটি WWW-Authenticate হেডার দিয়ে জবাব দেওয়া উচিত; আপনি একটি বৈধ টোকেন দিলে, একই রিকোয়েস্ট সফল হতে পারে। 403 Forbidden মানে আপনি অথেন্টিকেটেড কিন্তু অথরাইজড নন — আপনি প্রমাণ করেছেন আপনি কে এবং সার্ভার তা জানে, কিন্তু আপনার অ্যাকাউন্টের পারমিশন নেই। ভিন্ন ক্রেডেনশিয়াল সাহায্য করবে না; আপনার ভিন্ন পারমিশন দরকার। 405 Method Not Allowed নির্দিষ্ট: এন্ডপয়েন্ট বিদ্যমান কিন্তু আপনার ব্যবহৃত HTTP মেথড সমর্থন করে না। একটি GET /users এন্ডপয়েন্ট যা শুধু POST গ্রহণ করে 405 ফেরত দেবে এবং গৃহীত মেথড তালিকাভুক্ত একটি Allow হেডার অন্তর্ভুক্ত করতে হবে।

408 Request Timeout মানে ক্লায়েন্ট সম্পূর্ণ রিকোয়েস্ট পাঠাতে বেশি সময় নেওয়ার কারণে সার্ভার কানেকশন বন্ধ করেছে — ধীর মোবাইল সংযোগ বা বড় ফাইল আপলোডে সাধারণ। 409 Conflict একটি স্টেট সংঘাত সংকেত দেয়: রিকোয়েস্টটি বৈধ কিন্তু রিসোর্সের বর্তমান অবস্থা দেওয়া হলে পূরণ করা যায় না — আদর্শ উদাহরণ হলো এমন একটি রিসোর্স তৈরি করা যা ইতিমধ্যে বিদ্যমান (ডুপ্লিকেট ইউজারনেম, সংঘাতপূর্ণ ক্যালেন্ডার বুকিং)। 410 Gone হলো 404-এর স্পষ্ট বিকল্প: এটি ক্রলার ও ক্লায়েন্টদের বলে যে রিসোর্সটি বিদ্যমান ছিল, ইচ্ছাকৃতভাবে সরানো হয়েছে, এবং কখনও ফিরে আসবে না। সার্চ ইঞ্জিন একটি 410 পেজকে 404-এর চেয়ে দ্রুত তাদের ইনডেক্স থেকে সরিয়ে দেয় কারণ 404 একটি সাময়িক গ্লিচ হতে পারে। 422 Unprocessable Entity সিম্যান্টিক্যালি বৈধ রিকোয়েস্ট কভার করে যা ব্যবসায়িক লজিক ভ্যালিডেশনে ব্যর্থ হয় — JSON সঠিকভাবে গঠিত এবং রিকোয়েস্ট অথেন্টিকেটেড, কিন্তু মানগুলো নিজেই অবৈধ। 429 Too Many Requests হলো রেট-লিমিটিং কোড; এটি সবসময় সেকেন্ডের সংখ্যা বা একটি HTTP-তারিখ দেওয়া একটি Retry-After হেডার অন্তর্ভুক্ত করা উচিত যার পরে ক্লায়েন্ট আবার চেষ্টা করতে পারে।

5xx server error ক্লাসে, সূক্ষ্মতাগুলো ডিবাগিংয়ের জন্য গুরুত্বপূর্ণ। 500 Internal Server Error অহ্যান্ডলড এক্সসেপশনের ক্যাচ-অল — একটি স্ট্যাক ট্রেসের জন্য আপনার সার্ভার লগ চেক করুন। 502 Bad Gateway মানে একটি রিভার্স প্রক্সি (Nginx, একটি লোড ব্যালেন্সার, একটি CDN এজ নোড) আপনার আপস্ট্রিম অ্যাপ্লিকেশন সার্ভার থেকে একটি অবৈধ রেসপন্স পেয়েছে — অ্যাপ প্রসেসটি সম্ভবত ক্র্যাশ করেছে বা ভুলভাল ফিরিয়েছে। 503 Service Unavailable সংকেত দেয় সার্ভার ওভারলোড বা পরিকল্পিত মেইনটেন্যান্সের কারণে সাময়িকভাবে রিকোয়েস্ট হ্যান্ডেল করতে অক্ষম; একটি Retry-After হেডার অন্তর্ভুক্ত করুন যাতে ক্লায়েন্ট ও ক্রলার সার্ভারকে বারবার আঘাত না করে সুন্দরভাবে পিছু হটে। 504 Gateway Timeout 502 থেকে আলাদা এই যে আপস্ট্রিম সার্ভার অ্যাক্সেসযোগ্য ছিল কিন্তু প্রক্সির টাইমআউট উইন্ডোর মধ্যে সাড়া দেয়নি — একটি ধীর ডেটাবেস কোয়েরি বা একটি সাড়া না দেওয়া মাইক্রোসার্ভিস প্রায়ই এর কারণ। অন-কলে থাকলে, চেক করার ক্রম হলো: 500 → অ্যাপ লগ, 502 → অ্যাপ প্রসেস জীবিত কিনা, 503 → সার্ভার লোডের নিচে বা মেইনটেন্যান্স মোডে কিনা, 504 → কোন আপস্ট্রিম কল আটকে আছে।

REST API ডিজাইনে HTTP স্ট্যাটাস কোড: গুরুত্বপূর্ণ কনভেনশন

REST API ডিজাইন এমন অর্থ বহন করতে স্ট্যাটাস কোড ব্যবহার করার ওপর নির্ভর করে যা অন্যথায় রেসপন্স বডিতে ভারী হয়ে যেত। 200 বনাম 201 পার্থক্যটি সবচেয়ে সাধারণভাবে বাদ দেওয়া কনভেনশন: একটি POST /users এন্ডপয়েন্ট যা একটি ইউজার তৈরি করে 201 Created ফেরত দেওয়া উচিত একটি Location: /users/42 হেডারসহ, 200 নয়। প্রতিটি সফল রেসপন্সের জন্য 200 ফেরত দিলে API কনজিউমারদের কী ঘটেছে তা বুঝতে বডি পরীক্ষা করতে বাধ্য করে, যা প্রোগ্রামেটিক এরর হ্যান্ডলিং কঠিন করে তোলে এবং এমন টুল ভেঙে দেয় যা HTTP সিম্যান্টিক্সের ওপর নির্ভর করে — মনিটরিং ড্যাশবোর্ড, API গেটওয়ে এবং ইন্টিগ্রেশন টেস্ট সবই ভালো কাজ করে যখন স্ট্যাটাস কোড সঠিক অর্থ বহন করে। Stripe, GitHub এবং Twilio সবাই এই কনভেনশনটি সঠিকভাবে অনুসরণ করে, এবং তাদের SDK এর সুবিধা পায়।

DELETE-এর জন্য 204 বনাম 200 প্রশ্নটি একটি প্রকৃত ডিজাইন সিদ্ধান্ত। 204 No Content কোনো বডি ছাড়া পরিষ্কার মুছে ফেলার সংকেত দেয় — বডির অনুপস্থিতিই নিজেই নিশ্চিতকরণ, এবং HTTP ক্লায়েন্ট এটি দক্ষভাবে হ্যান্ডেল করে। কিছু টিম {"deleted": true, "id": 42}-এর মতো একটি JSON বডিসহ 200 ফেরত দেওয়া পছন্দ করে যাতে ফ্রন্টএন্ড ক্লায়েন্টদের একটি অনুপস্থিত বডির ওপর ভরসা না করেই স্পষ্ট নিশ্চিতকরণ দেওয়া যায়। কোনোটিই স্পেক লঙ্ঘন করে না, কিন্তু 204 বেশি ইডিয়মেটিক REST পছন্দ, এবং একই API-তে এন্ডপয়েন্টজুড়ে দুটি মেশানো বিভ্রান্তি তৈরি করে। একটি বেছে নিন এবং ডকুমেন্ট করুন। একটি সূক্ষ্মতা: আপনি যদি এমন একটি রিসোর্সের জন্য 204 ফেরত দেন যা ইতিমধ্যে চলে গিয়েছিল, তা সঠিক — আইডেমপোটেন্ট DELETE মানে দুইবার কল করলে দ্বিতীয়বার 404 ফেরত দেওয়া উচিত নয়।

মেজর API প্রোভাইডাররা কার্যকরভাবে ভ্যালিডেশন এররের জন্য 422 বনাম 400 সীমারেখা ঠিক করে দিয়েছে। 400 Bad Request-এর মানে হওয়া উচিত রিকোয়েস্টটি সিনট্যাক্টিক্যালি বিকৃত — পার্স করা যায় না এমন JSON, ভুল Content-Type, অনুপস্থিত প্রয়োজনীয় HTTP হেডার। 422 Unprocessable Entity-এর মানে হওয়া উচিত রিকোয়েস্টটি সঠিকভাবে গঠিত কিন্তু সিম্যান্টিক্যালি অবৈধ — একটি ইমেইল ফিল্ড যা বৈধ ইমেইল নয়, এমন একটি তারিখ রেঞ্জ যেখানে end শুরুর আগে, বা বিদ্যমান নেই এমন একটি ফরেন কী-র রেফারেন্স। Stripe, GitHub এবং বেশিরভাগ আধুনিক REST API ভ্যালিডেশন এররের জন্য 422 ফেরত দেয়, অপরাধী ফিল্ড তালিকাভুক্ত একটি স্ট্রাকচার্ড এরর বডির সাথে জোড়া দিয়ে। বিকল্প — বডিতে একটি এররসহ 200 ফেরত দেওয়া — API ডিজাইনের সবচেয়ে খারাপ প্যাটার্ন: এটি HTTP-লেভেল মনিটরিং ভেঙে দেয় (একটি 200 কোনো অ্যালার্টিং রুল ট্রিগার করবে না), প্রতিটি রেসপন্স বডি পার্স না করে এরর শনাক্ত করা অসম্ভব করে তোলে, এবং GraphQL-এর সব রেসপন্সের জন্য HTTP 200-এর ব্যাপক ব্যবহার (এররসহ যা একটি টপ-লেভেল errors অ্যারে বহন করে) বিতর্কিত হওয়ার কারণ — একটি স্ট্যান্ডার্ড HTTP মনিটরিং টুলের মাধ্যমে একটি GraphQL API ডিবাগ করা অ্যাপ্লিকেশন-লেভেল ব্যর্থতার প্রতি অন্ধ।