400 বনাম 422 ডেটার পোস্টের প্রতিক্রিয়া

Question

আমি কাজ করছি এমন "REST- এর মত" এপিআই দিয়ে বিভিন্ন পরিস্থিতিতে কী সঠিক অবস্থানের কোডটি ফিরিয়ে আনতে চেষ্টা করছি। ধরা যাক আমার কাছে একটি শেষ পয়েন্ট রয়েছে যা JSON ফর্ম্যাটে POST'ing ক্রয়ের অনুমতি দেয়। দেখে মনে হচ্ছে:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

ক্লায়েন্ট আমাকে "বিক্রয়_ট্যাক্স" (প্রত্যাশিত "ট্যাক্স" এর পরিবর্তে) প্রেরণ করলে আমি কী ফিরিয়ে দেব? বর্তমানে, আমি একটি 400 ফিরিয়ে দিচ্ছি But তবে, আমি নিজের সম্পর্কে এই প্রশ্নটি শুরু করেছি। আমি কি সত্যিই একটি 422 ফেরত আসব? মানে, এটি জেএসএন (যা সমর্থিত) এবং এটি বৈধ জেএসওএন, এটিতে প্রয়োজনীয় সমস্ত ক্ষেত্র নেই doesn't

Comments

আরএসটির

— অনিরুধ রমনাথন

Answer 1

400 খারাপ অনুরোধটি এখন আপনার ব্যবহারের ক্ষেত্রে সেরা HTTP / 1.1 স্থিতি কোড বলে মনে হচ্ছে।

আপনার প্রশ্নের (এবং আমার মূল উত্তর) সময়, আরএফসি 7231 কোনও জিনিস ছিল না; এই মুহুর্তে আমি আপত্তি জানালাম 400 Bad Requestকারণ আরএফসি 2616 বলেছে (জোর দিয়ে আমার):

অনুরোধটি ত্রুটিযুক্ত সিনট্যাক্সের কারণে সার্ভারের দ্বারা বোঝা গেল না ।

এবং আপনি যে অনুরোধটি বর্ণনা করেছেন তা সিন্ট্যাক্টিক্যালি বৈধ জেএসওএনকে সিন্ট্যাক্টিক্যালি বৈধ এইচটিটিপি-তে অন্তর্ভুক্ত করা হয়েছে এবং এইভাবে অনুরোধের সিনট্যাক্সের সাথে সার্ভারের কোনও সমস্যা নেই ।

তবে মন্তব্যে লি সাফারাইটের দ্বারা নির্দেশিত হিসাবে , আরএফসি 7231, যা আরএফসি 2616 কে অবিচ্ছিন্ন করে, সেই বিধিনিষেধকে অন্তর্ভুক্ত করে না :

৪০০ (খারাপ অনুরোধ) স্থিতি কোডটি ইঙ্গিত দেয় যে ক্লায়েন্ট ত্রুটি বলে মনে করা এমন কোনও কারণে (যেমন, বিকৃত অনুরোধ বাক্য গঠন, অবৈধ অনুরোধ বার্তা ফ্রেমিং, বা প্রতারণামূলক অনুরোধ রাউটিং) এর কারণে সার্ভার অনুরোধটি প্রক্রিয়া করতে বা করতে পারে না।

---

তবে, এই পুনরায় শব্দটির আগে (বা আপনি যদি এখনই প্রস্তাবিত স্ট্যান্ডার্ড হিসাবে আরএফসি 7231 সম্পর্কে প্রশ্ন করতে চান ), আপনার ব্যবহারের ক্ষেত্রে 422 Unprocessable Entityএকটি ভুল এইচটিটিপি স্থিতির কোড বলে মনে হচ্ছে না , কারণ আরএফসি 4918-এর ভূমিকা হিসাবে বলা হয়েছে:

যদিও HTTP / 1.1 দ্বারা প্রদত্ত স্থিতি কোডগুলি ওয়েবডিএভি পদ্ধতিগুলির দ্বারা দেখা বেশিরভাগ ত্রুটি শর্তটি বর্ণনা করার জন্য যথেষ্ট তবে কিছু ত্রুটি রয়েছে যা বিদ্যমান বিভাগগুলিতে ঝরঝরে পড়ে না। এই স্পেসিফিকেশনটি ওয়েবডিএভি পদ্ধতিগুলির জন্য উন্নত অতিরিক্ত স্থিতি কোডগুলি সংজ্ঞায়িত করে (বিভাগ 11)

এবং বর্ণনাটি422 বলে:

422 (অপ্রসারণযোগ্য সত্তা) স্থিতি কোডটির অর্থ সার্ভারটি অনুরোধ সত্তার সামগ্রীর ধরণটি বোঝে (অতএব একটি 415 (অসমর্থিত মিডিয়া প্রকার) স্থিতি কোড অনুপযুক্ত), এবং অনুরোধ সত্তার বাক্য গঠনটি সঠিক (সুতরাং 400) বাজে অনুরোধ ) স্থিতি কোড অনুপযুক্ত) তবে এতে থাকা নির্দেশাবলী প্রক্রিয়া করতে অক্ষম ছিল।

(সিনট্যাক্সের রেফারেন্সটি নোট করুন; আমি সন্দেহ করি 7231 আংশিকভাবে 4918 অচল করে ফেলেছি)

এই শব্দ ঠিক আপনার অবস্থা মতো কিন্তু ধরো যদি কোন সন্দেহ ছিল, এটা বলতে যায়:

উদাহরণস্বরূপ, যদি কোনও এক্সএমএল অনুরোধের শরীরে সু-গঠিত (যেমন সিন্টেক্সটিক্যালি সঠিক) থাকে তবে এই শব্দ ত্রুটিযুক্ত শর্তটি হতে পারে, এক্সএমএল নির্দেশাবলী se

("এক্সএমএল" কে "জেএসএন" দিয়ে প্রতিস্থাপন করুন এবং আমি মনে করি যে আমরা আপনার অবস্থার সাথে একমত হতে পারি)

এখন, কিছু আপত্তি করবে যে আরএফসি 4918 "ওয়েব বিতরণযোগ্য রচনাকরণ এবং সংস্করণকরণ (ওয়েবডিএভি) এর জন্য এইচটিটিপি এক্সটেনশনগুলি" সম্পর্কে এবং আপনি (সম্ভবত) ওয়েবডিএভি জড়িত কিছুই করছেন না যাতে এটি থেকে জিনিসগুলি ব্যবহার করা উচিত নয়।

মূল স্ট্যান্ডার্ডে একটি ত্রুটি কোড ব্যবহার করার মধ্যবর্তী পছন্দ দেওয়া হয়েছে যা স্পষ্টভাবে পরিস্থিতিটি আবৃত করে না, এবং কোনও এক্সটেনশান থেকে পরিস্থিতিটি ঠিক কী বর্ণনা করে, আমি পরবর্তীটি বেছে নেব।

তদ্ব্যতীত, আরএফসি 4918 ধারা 21.4 IANA হাইপারটেক্সট ট্রান্সফার প্রোটোকল (HTTP) স্থিতি কোড রেজিস্ট্রি বোঝায় , যেখানে 422 পাওয়া যাবে be

আমি প্রস্তাব দিচ্ছি যে কোনও HTTP ক্লায়েন্ট বা সার্ভারের জন্য এই রেজিস্ট্রি থেকে কোনও স্ট্যাটাস কোড ব্যবহার করা সম্পূর্ণ যুক্তিসঙ্গত, যতক্ষণ না তারা এগুলি সঠিকভাবে করে।

---

তবে HTTP / 1.1 হিসাবে, আরএফসি 7231 এর সারণি রয়েছে, সুতরাং কেবল ব্যবহার করুন 400 Bad Request!

Comments

আপনার উত্তর (422) আমার কাছে বোধগম্য। বৈধতা ত্রুটির কারণে কোনও রিসোর্স প্রক্রিয়া করা যায়নি, তখন এটিও রেল ( প্রতিক্রিয়া_ও ) ব্যবহার করে uses

— টাইলার রিক

নন-ওয়েবডিএভি

— বিশেষে

আপডেট হিসাবে ঠিক, আরএফসি 7231 এর প্রতিক্রিয়া কোড 400 এর পৃথক বর্ণনা রয়েছে যা শব্দার্থক পরিবর্তন করে।

— লি সাফেরাইট

আমার ক্ষমাপ্রার্থনা - আরএফসি-র পরিবর্তনগুলি প্রতিবিম্বিত করতে আমি এই উত্তরটি আপডেট করেছি এবং কিছু স্পষ্টতা হারিয়েছি; আমি রিফ্যাক্টর চেষ্টা করব। এটি প্রায় 422 ব্যবহার করা প্রায় নিরাপদ তবে আজকাল আপনার 400 ব্যবহার করা উচিত

— ক্রিশ্চিয়ান গ্লাস

আমি এখনও মনে করি অনুমানটি আরও পরিষ্কার হতে পারে। প্রদত্ত উদাহরণগুলি ক্লায়েন্টের কোনও ভুল কাজ করার স্পষ্ট ঘটনা are ওপি-র পরিস্থিতিও সেই শ্রেণিতে পড়ে। তবে, "আপনি যা জিজ্ঞাসা করছেন তা আমি বুঝতে পেরেছি, তবে এর বিরুদ্ধে কিছু ব্যবসায়ের নিয়ম রয়েছে বলে আমি এটি করতে অস্বীকার করি" এর মতো কেসগুলি এত পরিষ্কার কাটা নয়। এটি ঠিক ক্লায়েন্টের দোষ নয়, সুতরাং একই অনুমান অনুযায়ী 403 আসলে প্রয়োগ হতে পারে: "তবে, শংসাপত্রগুলির সাথে সম্পর্কিত না হওয়ার কারণে একটি অনুরোধ নিষিদ্ধ হতে পারে"। যদিও অনুমতি সম্পর্কিত স্টাফের জন্য "এটি করা যায় না" এর জন্য আমি আলাদা কোড রাখতে পছন্দ করি।

— থোররিন

Answer 2

400 খারাপ অনুরোধ আপনার ব্যবহারের ক্ষেত্রে সঠিক HTTP স্থিতি কোড। কোডটি HTTP / 0.9-1.1 আরএফসি দ্বারা সংজ্ঞায়িত করা হয়েছে।

অনুরোধটি ত্রুটিযুক্ত সিনট্যাক্সের কারণে সার্ভারের দ্বারা বোঝা গেল না। ক্লায়েন্ট পরিবর্তন ছাড়া অনুরোধ পুনরাবৃত্তি করা উচিত।

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 অপ্রয়োজনীয় সত্তা আরএফসি 4918 - ওয়েবডাভ দ্বারা সংজ্ঞায়িত করা হয়। নোট করুন যে 400 এর তুলনায় সামান্য পার্থক্য রয়েছে, নীচে উদ্ধৃত পাঠ্যটি দেখুন।

যদি কোনও এক্সএমএল অনুরোধের শৃঙ্খলে সুসংহত (যেমন সিন্টেক্সটিক্যালি সঠিক) থাকে তবে শব্দার্থগতভাবে ভ্রান্ত, এক্সএমএল নির্দেশাবলী থাকলে এই ত্রুটি শর্তটি দেখা দিতে পারে।

অভিন্ন ইন্টারফেস রাখতে আপনার কেবলমাত্র এক্সএমএল প্রতিক্রিয়াগুলির ক্ষেত্রে 422 ব্যবহার করা উচিত এবং কেবল 422 নয় ওয়েবডাভ এক্সটেনশান দ্বারা নির্ধারিত সমস্ত স্থিতি কোডগুলিও আপনার সমর্থন করা উচিত।

http://tools.ietf.org/html/rfc4918#page-78

স্থিতি কোডগুলিতে মার্ক নটিংহ্যামের পোস্টটিও দেখুন:

আপনার অ্যাপ্লিকেশনটির প্রতিটি অংশ এইচটিটিপি স্থিতি কোডগুলিতে "গভীরভাবে" ম্যাপ করার চেষ্টা করা একটি ভুল; বেশিরভাগ ক্ষেত্রে আপনি যে ধরণের গ্রানুলারিটির জন্য লক্ষ্য রাখতে চান তা অনেকটা মোটা হয়। যখন সন্দেহ হয়, জেনেরিক স্থিতি কোডগুলি 200 ওকে, 400 খারাপ অনুরোধ এবং 500 টি অভ্যন্তরীণ পরিষেবা ত্রুটি যখন আরও উপযুক্ত না হয় তখন ব্যবহার করা ঠিক ।

এইচটিটিপি স্থিতি কোড সম্পর্কে কীভাবে ভাববেন

Comments

৪২২ কোড আইএএনএ রেজিস্ট্রি এর অংশ ia.org/assignments/http-status-codes/http-status-codes.xhtml যাতে কোনও আইএমএইচওর কোনও ধারণা নেই। যে কোনও ক্ষেত্রে ফেসবুক এবং টুইটার আরএসটি এপিআই নিজস্ব কোডগুলি পুনরায় উদ্ভাবন করে এবং আরএফসি / আইএএনএ মান ব্যবহার করে না। সুতরাং আপনি করতে পারেন।

— gavenkoa

ধারা ১১-এ সুনির্দিষ্টভাবে বলা হয়েছে যে তারা কেবলমাত্র ওয়েবড্যাভের অনুমানের মধ্যেই নয়, পুরো কাহিনীতে যুক্ত হয়েছে:The following status codes are added to those defined in HTTP/1.1 [RFC2616].

— স্টিভ তৌবার

কোডটি ওয়েবডিএভি স্পেকের অংশ হিসাবে বর্ণনা করা হয়েছে বলে এর অর্থ এটি ওয়েবডিএভি-নির্দিষ্ট নয়! স্থিতি কোডগুলি জেনেরিক বলে মনে করা হয়।

— আপনার মোডগুলি ভাল

Answer 3

2015 হিসাবে স্থিতি প্রতিফলিত করতে:

আচরণগতভাবে 400 এবং 422 উভয় প্রতিক্রিয়া কোডগুলি ক্লায়েন্ট এবং মধ্যস্থতাকারীদের দ্বারা একই আচরণ করা হবে, সুতরাং এটি আপনার ব্যবহারের ক্ষেত্রে কোন তাত্পর্যপূর্ণ হবে না ।

তবে আমি প্রত্যাশা করছি যে বর্তমানে 400 টি আরও বেশি ব্যবহৃত হয়েছে, এবং এইচটিটিপিবিস স্পেস যে স্পষ্টতা দেয় তা এটিকে দুটি স্থিতির কোডের চেয়ে আরও উপযুক্ত করে তুলেছে :

• এইচটিটিপিবিস স্পষ্টভাবে সিনট্যাক্স ত্রুটিগুলির জন্য 400 না করার উদ্দেশ্য স্পষ্ট করে। বিস্তৃত বাক্যাংশ "ইঙ্গিত দেয় যে ক্লায়েন্টের ত্রুটি বলে মনে হচ্ছে এমন কোনও কারণে সার্ভার অনুরোধটি প্রক্রিয়াকরণ করতে বা করতে পারে না" এখন ব্যবহৃত হয়েছে।
• 422 বিশেষত একটি ওয়েবডিএভি এক্সটেনশন, এবং আরএফসি 2616 বা নতুন এইচটিটিপিবিস স্পেসিফিকেশনে উল্লেখ করা হয় না ।

প্রসঙ্গে, এইচটিটিপিবিস এইচটিটিপি / ১.১ অনুমানের একটি সংশোধন যা স্পষ্ট করে যেখানে অস্পষ্ট বা অসামঞ্জস্যপূর্ণ ক্ষেত্রগুলি পরিষ্কার করার চেষ্টা করে। এটি অনুমোদিত স্থিতিতে পৌঁছে গেলে এটি আরএফসি 2616 কে ছাড়িয়ে দেবে।

Comments

403 নিষিদ্ধ এছাড়াও এই প্রসঙ্গে ব্যবহার করা যেতে পারে না? উদ্ধৃতি: 403 (নিষিদ্ধ) স্থিতি কোডটি ইঙ্গিত দেয় যে সার্ভারটি অনুরোধটি বুঝতে পেরেছিল কিন্তু অনুমোদন দিতে অস্বীকৃতি জানায় ... অনুরোধে প্রমাণীকরণের শংসাপত্রগুলি সরবরাহ করা থাকলে সার্ভার তাদের অ্যাক্সেস দেওয়ার ক্ষেত্রে অপর্যাপ্ত বিবেচনা করে .... তবে, একটি অনুরোধ হতে পারে শংসাপত্রগুলির সাথে সম্পর্কিত না থাকার কারণে নিষিদ্ধ হবেন। সুতরাং দেখে মনে হচ্ছে 403 প্রমাণীকরণের বাইরে অনুরোধগুলি প্রত্যাখ্যান করতে ব্যবহার করা যেতে পারে।

— আবর্জনাবিহীন 22 ই

@garbagecollector নোট করুন যে " শংসাপত্রের বাইরের কারণে প্রত্যাখ্যান করা হয়েছে "! = " প্রমাণীকরণের বাইরের কারণে প্রত্যাখ্যান করা হয়েছে ।" নির্দিষ্টভাবে শংসাপত্র ব্যবহার না করে কাউকে প্রমাণীকরণের প্রচুর উপায় রয়েছে।

— ক্যানেটিক

@garbagecollector না, শংসাপত্রগুলির অর্থ প্রমাণীকরণ ("আপনি কে"), যা ব্যর্থতার পরে 401 হবে। অনুমোদন ("আপনি কী করতে পারেন") ব্যর্থতার পরে 403 হবে। এখানে সম্পূর্ণ ব্যাখ্যা: stackoverflow.com/a/6937030/137948 উভয়ই ওপি'র "নিখোঁজ ক্ষেত্রগুলি" পরিস্থিতির ক্ষেত্রে প্রযোজ্য নয় কারণ ত্রুটিটি একই রকম হবে নির্বিশেষে যে কোনও ব্যবহারকারী এটি চেষ্টা করেছিল। আমি সম্মত 400 সঠিক উত্তর।

— উইল Sheppard

Answer 4

কেস স্টাডি: গিটহাব এপিআই

https://developer.github.com/v3/#client-errors

সম্ভবত সুপরিচিত API গুলি থেকে অনুলিপি করা একটি বুদ্ধিমান ধারণা:

অনুরোধ সংস্থাগুলি প্রাপ্ত এপিআই কলগুলিতে তিনটি সম্ভাব্য ক্লায়েন্ট ত্রুটি রয়েছে:

অবৈধ জেএসএন প্রেরণের ফলে 400 টি বাজে অনুরোধের প্রতিক্রিয়া হবে।

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

ভুল ধরণের JSON মান পাঠানোর ফলে 400 টিও খারাপ অনুরোধের প্রতিক্রিয়া হবে।

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

অবৈধ ক্ষেত্রগুলি প্রেরণের ফলে 422 অপ্র্যাকোসেসযোগ্য সত্তার প্রতিক্রিয়া দেখাবে।

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Comments

আমি মনে করি এটি সঠিক এবং বোধগম্য উত্তর।

— লেমনুড এডানে

এটি আরও উত্সাহ দিতে পারে না। আরও উচ্চতর উত্তরগুলি এই উত্তরটি উল্লেখ করে। স্পেসগুলি (আরএফসি, আইএএনএ) দুটি ক্ষেত্রে স্পষ্ট সংজ্ঞা এবং পার্থক্য সরবরাহ করতে ব্যর্থ হয়েছে। সুতরাং উত্তরটি সর্বোত্তম অনুশীলনে উত্সাহিত করে এবং গিটহাব আমাদের একটি দেয়।

— অ্যালেক্স ক্লাউস

Answer 5

কোনও সঠিক উত্তর নেই, যেহেতু এটি আপনার অনুরোধের জন্য "সিনট্যাক্স" এর সংজ্ঞাটি নির্ভর করে। সবচেয়ে গুরুত্বপূর্ণ বিষয়টি হ'ল আপনি:

1. ধারাবাহিকভাবে প্রতিক্রিয়া কোড ব্যবহার করুন
2. আপনার এপিআই চিত্রটি কী চলছে তা নির্ধারণের জন্য বিকাশকারীদের সহায়তা করতে সাড়া বডিতে যতটা অতিরিক্ত তথ্য অন্তর্ভুক্ত করুন =

এখানে কোনও সঠিক বা ভুল উত্তর নেই বলার জন্য সবাই আমার চারপাশে লাফ দেওয়ার আগে, আমি কীভাবে উপসংহারে এসেছি সে সম্পর্কে কিছুটা ব্যাখ্যা করি।

এই নির্দিষ্ট উদাহরণে, ওপির প্রশ্নটি জেএসএন অনুরোধ সম্পর্কিত যা প্রত্যাশার চেয়ে আলাদা কী রয়েছে। এখন, প্রাপ্ত মূল নামটি একটি প্রাকৃতিক ভাষার দৃষ্টিকোণ থেকে, প্রত্যাশিত কী হিসাবে খুব মিল, তবে এটি কঠোরভাবে, পৃথক, এবং সুতরাং (সাধারণত) কোনও মেশিন দ্বারা সমতুল্য হিসাবে স্বীকৃত নয়।

যেমন আমি উপরে বলেছি, সিদ্ধান্ত গ্রহণকারী ফ্যাক্টরটি সিনট্যাক্স বলতে বোঝায় । যদি অনুরোধটি কোনও সামগ্রী প্রকারের সাথে প্রেরণ করা হয়েছিল application/json, তবে হ্যাঁ, অনুরোধটি সিনট্যাকটিকভাবে বৈধ কারণ এটি বৈধ JSON সিনট্যাক্স, তবে শব্দার্থগতভাবে বৈধ নয়, কারণ এটি প্রত্যাশার সাথে মিলছে না। (প্রশ্নটিতে অনুরোধটি শব্দার্থগতভাবে বৈধ কিনা বা না তার একটি কঠোর সংজ্ঞা ধরে নেওয়া)।

অন্যদিকে, অনুরোধটি যদি আরও নির্দিষ্ট কাস্টম সামগ্রীর প্রকারের সাথে প্রেরণ করা হয়েছিল application/vnd.mycorp.mydatatype+json, সম্ভবত, ক্ষেত্রগুলি কী প্রত্যাশা করা হচ্ছে ঠিক তা নির্দিষ্ট করে দেয়, তবে আমি বলব যে অনুরোধটি সিনট্যাক্টিকভাবে অবৈধ হতে পারে, সুতরাং 400 প্রতিক্রিয়া।

প্রশ্নের ক্ষেত্রে, যেহেতু কীটি ভুল ছিল, মানটি নয় , বৈধ কীগুলি কী কী তার জন্য কোনও স্পেসিফিকেশন থাকলে সেখানে একটি বাক্য গঠন ত্রুটি ছিল । বৈধ কীগুলির জন্য কোনও স্পেসিফিকেশন না থাকলে , বা ত্রুটিটি কোনও মান সহ ছিল , তবে এটি হবে অর্থগত ত্রুটি হবে।

Comments

খুব আন্ডাররেটেড উত্তর - ভাল শব্দযুক্ত ব্যাখ্যার জন্য ধন্যবাদ।

— পুউইউ

বিষয়টি সম্পর্কে ঠিক আমার চিন্তাভাবনা! আমি এক্সএমএল এসওএপি ব্যাকগ্রাউন্ড থেকে আসছি এবং স্কিমার ধারণাটি আমার রক্তে প্রবেশ করেছে এবং জেএসওএন নথিগুলি তাদের স্কিমা ঘোষণা করবেন না। আমার কাছে এটি সার্ভারের অনুরোধটি "বোঝে" কিনা তা নয়। সার্ভার যদি "বিক্রয়_ট্যাক্স" কী তা জানে না তবে এটি কেবল 400: "আপনি আমাকে কী পাঠিয়েছেন তা আমার কোনও ধারণা নেই তবে আমি যা চাই তা অবশ্যই তা নয়" "

— আলেকসান্দার স্টেলম্যাকজোনেক

Answer 6

422 অপ্রয়োজনীয় সত্তা ব্যাখ্যা করা হয়েছে: মার্চ 6, 2017

422 অপ্রয়োজনীয় সত্তা কী?

একটি 422 স্থিতি কোডটি ঘটে যখন একটি অনুরোধটি ভালভাবে গঠন করা হয়, তবে শব্দার্থক ত্রুটির কারণে এটি প্রক্রিয়া করা যায় না। এই এইচটিটিপি স্থিতিটি আরএফসি 4918-এ প্রবর্তিত হয়েছিল এবং ওয়েব বিতরণযোগ্য রচনাকরণ এবং সংস্করণকরণ (ওয়েবডিএভি) এর জন্য এইচটিটিপি এক্সটেনশনের দিকে আরও বিশেষভাবে তীক্ষ্ণ।

বিকাশকারীদের ক্লায়েন্টদের 400 বনাম 422 ত্রুটি ফিরিয়ে আনা উচিত কিনা তা নিয়ে কিছুটা বিতর্ক রয়েছে (নীচের উভয় স্ট্যাটাসের মধ্যে পার্থক্য সম্পর্কে আরও)। যাইহোক, বেশিরভাগ ক্ষেত্রে, আপনি যদি ওয়েবডিএভি সক্ষমতা সমর্থন করেন তবেই 422 স্থিতিটি ফিরিয়ে দেওয়া উচিত বলে একমত হয়।

আরএফসি 4918 এর বিভাগ 11.2 থেকে নেওয়া 422 স্থিতির কোডটির একটি শব্দ-সংজ্ঞা নীচে পড়তে পারে।

422 (অপ্রসারণযোগ্য সত্তা) স্থিতি কোডটির অর্থ সার্ভারটি অনুরোধ সত্তার সামগ্রীর ধরণটি বোঝে (অতএব একটি 415 (অসমর্থিত মিডিয়া প্রকার) স্থিতি কোড অনুপযুক্ত), এবং অনুরোধ সত্তার বাক্য গঠনটি সঠিক (সুতরাং 400) বাজে অনুরোধ ) স্থিতি কোড অনুপযুক্ত) তবে এতে থাকা নির্দেশাবলী প্রক্রিয়া করতে অক্ষম ছিল।

সংজ্ঞাটি বলতে থাকে:

উদাহরণস্বরূপ, যদি কোনও এক্সএমএল অনুরোধের শরীরে সু-গঠিত (যেমন সিন্টেক্সটিক্যালি সঠিক) থাকে তবে এই শব্দ ত্রুটিযুক্ত শর্তটি হতে পারে, এক্সএমএল নির্দেশাবলী se

400 বনাম 422 স্থিতি কোড

খারাপ অনুরোধ ত্রুটিগুলি 400 টি স্ট্যাটাস কোড ব্যবহার করে এবং যদি অনুরোধ বাক্য গঠনটি ত্রুটিযুক্ত থাকে, অবৈধ অনুরোধ বার্তা ফ্রেমিং থাকে বা ভ্রান্ত অনুরোধের রাউটিং থাকে তবে ক্লায়েন্টকে ফিরিয়ে দেওয়া উচিত। এই স্থিতি কোডটি 422 অপ্রাপ্তিমূলক সত্তার স্থিতির সাথে বেশ সমান মনে হতে পারে, তবে, তথ্যের একটি ছোট অংশ যা আলাদা করে দেয় তা হল 422 ত্রুটির জন্য একটি অনুরোধ সত্তার বাক্য গঠনটি সঠিক যেখানে একটি অনুরোধের বাক্য গঠন যা 400 উত্পন্ন করে ত্রুটিটি ভুল।

422 স্থিতির ব্যবহার কেবলমাত্র বিশেষ ব্যবহারের ক্ষেত্রে সংরক্ষণ করা উচিত। অন্যান্য বেশিরভাগ ক্ষেত্রে যেখানে খণ্ডিত সিনট্যাক্সের কারণে ক্লায়েন্ট ত্রুটি ঘটেছে, 400 খারাপ অনুরোধের স্থিতি ব্যবহার করা উচিত।

https://www.keycdn.com/support/422-unprocessable-entity/

Answer 7

আপনার ক্ষেত্রে: HTTP 400 REST দৃষ্টিকোণ থেকে আপনার ক্ষেত্রে সঠিক অবস্থানের কোড কারণ এটি বৈধ জেএসওনের sales_taxপরিবর্তে প্রেরণে সিন্টেক্সিকভাবে ভুল tax। JSON অবজেক্টে ম্যাপিং করার সময় এটি বেশিরভাগ সার্ভার সাইড ফ্রেমওয়ার্ক দ্বারা প্রয়োগ করা হয়। তবে, কিছু REST বাস্তবায়ন রয়েছে যা keyJSON অবজেক্টে নতুন উপেক্ষা করে । content-typeসেক্ষেত্রে কেবল বৈধ ক্ষেত্র গ্রহণের জন্য একটি কাস্টম স্পেসিফিকেশন সার্ভার-সাইড দ্বারা প্রয়োগ করা যেতে পারে।

422 এর জন্য আদর্শ পরিস্থিতি:

আদর্শ বিশ্বে, 422 টি পছন্দসই এবং প্রতিক্রিয়া হিসাবে পাঠানোর জন্য সাধারণত গ্রহণযোগ্য হয় যদি সার্ভারটি অনুরোধ সত্তার সামগ্রীর ধরণটি বোঝে এবং অনুরোধ সত্তার বাক্য গঠন সঠিক হয় তবে ডেটা প্রক্রিয়া করতে অক্ষম হয় কারণ এর শব্দার্থগতভাবে ভুল।

৪২২ ওভারের পরিস্থিতি ৪২২:

মনে রাখবেন, প্রতিক্রিয়া কোড 422 একটি বর্ধিত এইচটিটিপি (ওয়েবডিএভি) স্থিতি কোড। এখনও কিছু HTTP ক্লায়েন্ট / ফ্রন্ট-এন্ড লাইব্রেরি রয়েছে যা 422 হ্যান্ডেল করার জন্য প্রস্তুত নয় them তাদের জন্য এটি "HTTP 422 এর মতোই ভুল, কারণ এটি HTTP নয়" । পরিষেবা দৃষ্টিকোণ থেকে, 400 যথেষ্ট নির্দিষ্ট নয়।

এন্টারপ্রাইজ আর্কিটেকচারে, সার্ভিসগুলি বেশিরভাগ এসওএ, আইডিএম ইত্যাদির মতো পরিষেবা স্তরগুলিতে স্থাপন করা হয় a যদি ক্লায়েন্টগুলির মধ্যে একটি এইচটিটিপি 422 পরিচালনা করে না, বিকল্পগুলি হ'ল ক্লায়েন্টকে প্রত্যেকের জন্য আপনার প্রতিক্রিয়া কোডটি এইচটিটিপি 400 এ পরিবর্তন করতে বা তার কাছে পরিবর্তন করতে বলা। আমার অভিজ্ঞতায়, আজকাল এটি খুব বিরল তবে এখনও সম্ভাবনা। সুতরাং, এইচটিটিপি প্রতিক্রিয়া কোডগুলি সিদ্ধান্ত নেওয়ার আগে আপনার আর্কিটেকচারের সতর্কতার সাথে অধ্যয়ন করা প্রয়োজন।

এগুলির মতো পরিস্থিতি পরিচালনা করতে, পরিষেবা স্তরগুলি সাধারণত 400 টি প্রেরণের জন্য কঠোর এইচটিটিপি কনফারেন্স ক্লায়েন্টদের জন্য পতাকা versioningসেটআপ করে বা configurationতার বাকি অংশের জন্য 422 প্রেরণ করে। এইভাবে তারা বিদ্যমান গ্রাহকদের জন্য পিছনে সামঞ্জস্যতা সমর্থন সরবরাহ করে তবে একই সাথে নতুন ক্লায়েন্টদের এইচটিটিপি 422 গ্রাহনের ক্ষমতা সরবরাহ করে।

---

আরএফসি 7321 এর সর্বশেষ আপডেট বলে:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

এটি নিশ্চিত করে যে সার্ভারগুলি অবৈধ অনুরোধের জন্য HTTP 400 প্রেরণ করতে পারে। 400 কেবলমাত্র সিনট্যাক্স ত্রুটির বিষয়ে উল্লেখ করে না , তবে, ক্লায়েন্টরা এটি পরিচালনা করতে পারলে 422 এখনও একটি আসল প্রতিক্রিয়া।

Answer 8

প্রথমত এটি খুব ভাল প্রশ্ন।

400 খারাপ অনুরোধ - যখন তথ্যটির একটি সমালোচনামূলক অংশটি অনুরোধ থেকে হারিয়ে যায়

যেমন অনুমোদনের শিরোনাম বা বিষয়বস্তুর ধরণের শিরোনাম। যা অনুরোধটি বুঝতে সার্ভারের দ্বারা একেবারে প্রয়োজনীয়। এটি সার্ভার থেকে সার্ভারে পৃথক হতে পারে।

422 অপ্রয়োজনীয় সত্তা - যখন অনুরোধের বডিটি বিশ্লেষণ করা যায় না।

এটি 400 এর চেয়ে কম গুরুতর is অনুরোধটি সার্ভারে পৌঁছেছে। সার্ভারটি স্বীকৃতি জানিয়েছে যে অনুরোধটি মূল কাঠামোটি সঠিকভাবে পেয়েছে। তবে অনুরোধের বুকের তথ্য পার্স করা বা বোঝা যায় না।

যেমন Content-Type: application/xmlযখন অনুরোধের বডিটি জেএসএন হয় ON

এখানে আর্টিকাল এপিআইগুলিতে স্থিতি কোডগুলির তালিকা এবং এর ব্যবহারের একটি নিবন্ধ রয়েছে। https://metamug.com/article/status-codes-for-rest-api.php

Comments

422 এর অর্থ সিনট্যাক্সটি বৈধ, তবে সামগ্রীগুলি নয়। এক্সএমএল প্রত্যাশিত যেখানে জেএসএন প্রেরণের অর্থ সিনট্যাক্সটি ভুল, সুতরাং 400 এই ক্ষেত্রে সঠিক প্রতিক্রিয়া।

— ডার্ক

ডার্ক ঠিক ঠিক যেমন বলেছিলেন 422 এর অর্থ সিন্ট্যাক্টিক্যালি বৈধ অনুরোধ (পার্স করা এবং বোঝা যায়) তবে শব্দার্থগতভাবে অবৈধ

— জ্যাসেক ওবরিমস্কি

400: যখন অবৈধ সিনট্যাক্সের কারণে অনুরোধটি প্রক্রিয়া করা যায় না (যেমন পার্সিং ত্রুটি); 422: যখন অবৈধ ডেটার (যেমন বৈধতা ত্রুটি) কারণে অনুরোধটি প্রক্রিয়া করা যায় না।

— কিটনোটোরি

কারণ একটি অ্যাপ্লিকেশন / XML মিডিয়া টাইপ সঙ্গে JSON পাঠিয়ে, শরীর স্বয়ংক্রিয়ভাবে চিহ্নগুলি সিন্টেক্সের ভুল এবং প্রতিক্রিয়া হওয়া উচিত 400 422 জন্য উদাহরণ বৈধ নয়

— manemarron

Answer 9

আপনার আসলে "200 ওকে" ফিরিয়ে দেওয়া উচিত এবং প্রতিক্রিয়া সংস্থায় পোস্ট করা ডেটার সাথে কী ঘটেছিল সে সম্পর্কে একটি বার্তা অন্তর্ভুক্ত করা উচিত। তারপরে বার্তাটি বোঝার জন্য এটি আপনার আবেদনের উপর নির্ভর করে।

জিনিসটি হ'ল, HTTP স্থিতি কোডগুলি হ'ল - HTTP স্থিতি কোডগুলি codes এবং এগুলি কেবল পরিবহন স্তরে অর্থ প্রয়োগ করতে বোঝানো হয়, অ্যাপ্লিকেশন স্তরে নয়। অ্যাপ্লিকেশন স্তরটি সত্যই কখনও জানে না যে এইচটিটিপি ব্যবহৃত হচ্ছে। আপনি যদি এইচটিটিপি থেকে হোমিং কবুতরে আপনার পরিবহণ স্তরটি পরিবর্তন করেন তবে এটি কোনওভাবেই আপনার অ্যাপ্লিকেশন স্তরকে প্রভাবিত করবে না।

আমি আপনাকে একটি ভার্চুয়াল উদাহরণ দেই। ধরা যাক আপনি কোনও মেয়ের প্রেমে পড়েছেন এবং তিনি আপনাকে ফিরে আসতে ভালোবাসেন তবে তার পরিবার সম্পূর্ণ ভিন্ন দেশে চলে যায়। তিনি আপনাকে তার নতুন শামুক-মেল ঠিকানা দেয়। স্বাভাবিকভাবেই, আপনি তাকে একটি প্রেমের চিঠি প্রেরণ করার সিদ্ধান্ত নিয়েছেন। সুতরাং আপনি আপনার চিঠিটি লিখুন, এটি একটি খামে রাখুন, খামে তার ঠিকানা লিখুন, এটির উপর একটি স্ট্যাম্প লাগিয়ে প্রেরণ করবেন। এখন এই পরিস্থিতি বিবেচনা করা যাক

1. আপনি রাস্তার নাম লিখতে ভুলে গেছেন। আপনি একটি খোলার চিঠি ফিরে পাবেন যাতে এতে একটি বার্তা লেখা আছে যাতে ঠিকানাটি ত্রুটিযুক্ত। আপনি অনুরোধটি ভুল করেছেন এবং প্রাপ্ত ডাকঘর এটি পরিচালনা করতে অক্ষম। এটি "400 খারাপ অনুরোধ" পাওয়ার সমতুল্য।
2. সুতরাং আপনি ঠিকানা ঠিক করুন এবং আবার চিঠিটি প্রেরণ করুন। তবে কিছু দুর্ভাগ্যের কারণে আপনি মোটামুটি রাস্তার নামটি ভুল বানান করেছিলেন। আপনি চিঠিটি আবার একটি বার্তায় ফিরে পাবেন যাতে এই ঠিকানাটির অস্তিত্ব নেই। এটি "404 পাওয়া যায়নি" পাওয়ার সমতুল্য।
3. আপনি ঠিক আবার ঠিকানা ঠিক করুন এবং এই সময় আপনি ঠিকভাবে ঠিকানা লিখতে পরিচালনা। আপনার মেয়েটি চিঠিটি পেয়েছে এবং আপনাকে আবার লিখবে। এটি "200 ওকে" পাওয়ার সমতুল্য। তবে এর অর্থ এই নয় যে তিনি তার চিঠিতে যা লিখেছেন তা আপনার পছন্দ হবে। এর সহজ অর্থ হ'ল তিনি আপনার বার্তাটি পেয়েছেন এবং আপনার প্রতিক্রিয়া রয়েছে has আপনি খামটি খোলার এবং তার চিঠিটি না পড়া পর্যন্ত আপনি জানতে পারবেন না যে সে আপনাকে খুব প্রিয়ভাবে মিস করে বা আপনার সাথে সম্পর্ক ছিন্ন করতে চায়।

সংক্ষেপে: "200 ওকে" ফিরিয়ে দেওয়ার অর্থ এই নয় যে সার্ভার অ্যাপটি আপনার জন্য সুসংবাদ রয়েছে। এর অর্থ কেবল এটির কিছু সংবাদ রয়েছে।

PS: 422 স্থিতি কোডটির কেবলমাত্র ওয়েবডিএভি প্রসঙ্গে একটি অর্থ রয়েছে। আপনি যদি ওয়েবডিএভি নিয়ে কাজ করছেন না, তবে 422 এর অন্য মানহীন কোড = এর মতো একই স্ট্যান্ডার্ড অর্থটি = যা কোনওটি নয়।