ব্যর্থ বৈধতা বা অবৈধ সদৃশ জন্য REST HTTP স্থিতি কোডগুলি


825

আমি একটি আরইএসটি-ভিত্তিক এপিআই দিয়ে একটি অ্যাপ্লিকেশন তৈরি করছি এবং আমি প্রতিটি অনুরোধের জন্য স্থিতি কোডগুলি নির্দিষ্ট করছি এমন জায়গায় এসে পৌঁছেছি।

বৈধতা ব্যর্থ হওয়ার অনুরোধের জন্য বা যেখানে একটি অনুরোধ আমার ডাটাবেসে একটি সদৃশ যোগ করার চেষ্টা করছে তার জন্য আমি কোন স্থিতি কোড পাঠাব?

আমি http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html দেখেছি কিন্তু এগুলির কোনওটিই সঠিক বলে মনে হচ্ছে না।

স্থিতি কোড পাঠানোর সময় কি প্রচলিত অনুশীলন রয়েছে?



14
Httpstatus.es খুলুন , ডান ক্লিক করুন >> পিন ট্যাব: পি
সালমান ভন আব্বাস

উত্তর:


778

ইনপুট বৈধতা ব্যর্থতার জন্য: 400 খারাপ অনুরোধ + আপনার alচ্ছিক বিবরণ। এটি " RESTful Web Services " বইয়ে পরামর্শ দেওয়া হয়েছে । ডাবল জমা দেওয়ার জন্য: 409 সংঘাত


জুন 2014 আপডেট করুন

প্রাসঙ্গিক স্পেসিফিকেশনটি আরএফসি 2616 হিসাবে ব্যবহৃত হত , যা 400 (খারাপ অনুরোধ) এর পরিবর্তে সংকীর্ণ হিসাবে ব্যবহার করেছিল

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

সুতরাং এটি যুক্তিযুক্ত হতে পারে যে এটি শব্দার্থত ত্রুটির জন্য অনুপযুক্ত। কিন্তু আর কখনো না; জুন ২০১৪ সাল থেকে প্রাসঙ্গিক স্ট্যান্ডার্ড আরএফসি 7231 , যা পূর্বের আরএফসি 2616 ছাড়িয়ে যায়, 400 এর (খারাপ অনুরোধ) আরও বিস্তৃত হিসাবে ব্যবহার দেয়

ক্লায়েন্টের ত্রুটি বলে মনে হয় এমন কোনও কারণে সার্ভারটি অনুরোধটি প্রক্রিয়া করতে পারে না বা করবে না


3
হ্যাঁ, অনুরোধের বডিটি সিনট্যাক্সের অংশ।
Deamon

62
খারাপ অনুরোধ অবশ্যই এই ধরণের ইস্যুতে সর্বাধিক সাধারণ প্রতিক্রিয়া। কেবলমাত্র অন্য বিকল্পটি হল 422 অপ্রয়োজনীয় সত্তা। এটি আসলে ওয়েবড্যাভ থেকে এসেছে তবে আইএএনএ-র সাথে নিবন্ধিত কোনও স্ট্যাটাস কোডটি পুনরায় ব্যবহার করা পুরোপুরি বৈধ।
ড্যারেল মিলার 20'10

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

18
আমি আপনার আরএফসি 7231 এর ব্যাখ্যার সাথে একমত নই, যদিও এতে বলা হয়েছে যে something perceived to be a client error, এই অনুচ্ছেদে প্রদত্ত সমস্ত উদাহরণ HTTP প্রোটোকলের লঙ্ঘন, যৌক্তিক ত্রুটি নয়: বাক্য গঠন, ফ্রেমিং, রাউটিং। সুতরাং, আমি বিবেচনা করি যে এইচটিটিপি স্পেক অ্যাপ্লিকেশন পর্যায়ে ব্যর্থ বৈধতার জন্য 400 কে মঞ্জুরি দেয় না
দিমা তিসনেক

2
কেন একটি 422 - অপ্রয়োজনীয় সত্তা ব্যবহার করবেন না? আমার কাছে আরও যুক্তিযুক্ত বলে মনে হচ্ছে
java_geek

278
  • ব্যর্থতা বৈধতা: 403 নিষিদ্ধ ("সার্ভারটি অনুরোধটি বুঝতে পেরেছিল, তবে এটি পূরণ করতে অস্বীকার করছে")। জনপ্রিয় মতামতের বিপরীতে, আরএফসি 2616 "403 কেবলমাত্র ব্যর্থ প্রমাণীকরণের উদ্দেশ্যে তৈরি করা হয়েছে" বলে না, তবে "403: আমি জানি আপনি কী চান, তবে আমি এটি করব না"। সেই শর্তটি প্রমাণীকরণের কারণে হতে পারে বা নাও হতে পারে।
  • একটি সদৃশ যোগ করার চেষ্টা করা হচ্ছে: 409 সংঘাত ("রিসোর্সের বর্তমান অবস্থার সাথে বিরোধের কারণে অনুরোধটি শেষ করা যায়নি" ")

আপনার অবশ্যই প্রতিক্রিয়া শিরোনাম এবং / অথবা বডি (যেমন কাস্টম শিরোনাম সহ - X-Status-Reason: Validation failed) এ আরও বিশদ বিবরণ দেওয়া উচিত ।


17
@deamon: যে না স্পেসিফিকেশন, উইকিপিডিয়ার অর্থাৎ কারো মতামত "কি HTTP স্থিতি কোড মানে"; নোট করুন যে পৃষ্ঠাটি প্রয়োজনীয়ভাবে বলেছে "403 এর সাথে আপাচি এর অর্থ এটি, আইআইএস 403 এর সাথে এটিই বোঝায়", এবং কোথাও এটি অফিসিয়াল আরএফসি'র উল্লেখ নেই। আপনি "403 এর অর্থ যা অ্যাপাচি যা বলে তাই" পুনরাবৃত্তি করছেন বলে মনে হচ্ছে। না. আসল আরএফসি (যা প্রাসঙ্গিক দলিল, অ্যাপাচি বাস্তবায়ন নয়, আইআইএস বাস্তবায়ন নয়, অন্য কারও বাস্তবায়ন নয়) এখানে রয়েছে: w3.org/Protocols/rfc2616/rfc2616-sec10.html
পিসকভার

57
"10.4.4 403 নিষিদ্ধ সার্ভারটি অনুরোধটি বুঝতে পেরেছিল, তবে তা পূরণ করতে অস্বীকার করছে Author অনুমোদন সাহায্য করবে না এবং অনুরোধটির পুনরাবৃত্তি করা উচিত নয় If পরিপূর্ণ হয়ে গেছে, এটি সত্তার অস্বীকারের কারণ বর্ণনা করতে হবে the সার্ভার যদি এই তথ্য ক্লায়েন্টের কাছে উপলব্ধ করতে না চায় তবে স্থিতি কোড 404 (পাওয়া যায়নি) পরিবর্তে ব্যবহার করা যেতে পারে "" আমি সেখানে কোনও জোর দেখছি না ("করানো উচিত / উচিত নয়" আরএফসি 2119 কীওয়ার্ড, জোর নয়); আরএফসির নয়, "নিষিদ্ধ" এর অর্থ কী এটি আপনার ধারণা।
পিসকভোর

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

2
ত্রুটি বার্তার জন্য নিজেই কারণ বাক্যটি সংশোধন করা উচিত, সুতরাং শিরোনাম পাঠানো HTTP/1.0 403 Form validation errorsসবচেয়ে পরিষ্কার উপায় way
আলেম্ব

6
আইএমও, 422 "অপ্রয়োজনীয় সত্তা" আরও বেশি অর্থবোধ করে। আমার যুক্তিটি হ'ল এটি নয় যে সার্ভার অনুরোধটি পূরণ করতে অস্বীকার করে, সার্ভারটি অনুরোধটি পূরণ করতে পারে না
tybro0103

225

আমি স্থিতি কোডটি 422, "অপ্রয়োজনীয় সত্তা" প্রস্তাব দিই ।

11.2। 422 অপ্রয়োজনীয় সত্তা

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


11
অবশ্যই এটি একটি এইচটিটিপি স্থিতির কোড, iana.org/assignments/http-status-codes দেখুন । আরএফসি 2616
জুলিয়ান রেচকে

7
ওয়েবডিএভি হ'ল এইচটিটিপি এক্সটেনশন । "ওয়েব বিতরণযোগ্য রচনাকরণ এবং সংস্করণকরণের জন্য এইচটিটিপি এক্সটেনশানস (ওয়েবডিএভি)" সুতরাং, স্থিতি কোড 422 কোনও এইচটিসি স্থিতি কোড নয়, তবে এইচটিপি-র একটি অংশের স্ট্যাটাস কোড।
ডিমানন

16
ডিমন, এটি বোঝা যায় না। এইচটিটিপি কীভাবে নতুন কোডগুলি সংজ্ঞায়িত করতে পারে এবং ওয়েবডিএভি এটি করছে। একটি কারণে স্থিতি কোড রেজিস্ট্রি রয়েছে।
জুলিয়ান রিশচে

14
FYI - 422: 11.2 এর আরএফসি বিবরণ। 422 অপ্রয়োজনীয় সত্তা 422 (অপ্রসারণযোগ্য সত্তা) স্থিতি কোডটির অর্থ সার্ভারটি অনুরোধ সত্তার সামগ্রীর ধরণটি বোঝে (অতএব একটি 415 (অসমর্থিত মিডিয়া প্রকার) স্থিতি কোড অনুপযুক্ত), এবং অনুরোধ সত্তার বাক্য গঠনটি সঠিক (সুতরাং 400) (খারাপ অনুরোধ) স্থিতি কোড অনুপযুক্ত) তবে এতে থাকা নির্দেশাবলী প্রক্রিয়া করতে অক্ষম। উদাহরণস্বরূপ, যদি কোনও এক্সএমএল অনুরোধের শরীরে সু-গঠিত (যেমন সিন্টেক্সটিক্যালি সঠিক) থাকে তবে এই শব্দ ত্রুটিযুক্ত শর্তটি হতে পারে, এক্সএমএল নির্দেশাবলী se
স্টিভ কালেস্টেদ

6
এবং থ্রেডগুলি 'মেয়াদোত্তীর্ণ' হয় না। এগুলিকে বাঁচিয়ে রাখতে হবে বা শীর্ষস্থানীয় গুগল অনুসন্ধান ফলাফলগুলি ভুল হতে শুরু করে।
জেমস বিলিংহাম

81

200,300, 400, 500 সবই খুব জেনেরিক। আপনি যদি জেনেরিক চান তবে 400 টি ঠিক আছে।

422 টি ক্রমবর্ধমান এপিআই দ্বারা ব্যবহৃত হয়, এবং এমনকি বাক্সের বাইরেও রেলগুলি দ্বারা ব্যবহৃত হয়।

আপনি আপনার এপিআইয়ের জন্য কোন স্ট্যাটাস কোডটি বেছে নিচ্ছেন না কেন, কেউই এতে দ্বিমত পোষণ করবেন। তবে আমি 422 পছন্দ করি কারণ আমি '400 + পাঠ্য স্থিতি' খুব সাধারণ হিসাবে মনে করি। এছাড়াও, আপনি জেএসএন-রেডি পার্সারের সুবিধা নিচ্ছেন না; বিপরীতে, একটি JSON প্রতিক্রিয়া সহ একটি 422 খুব সুস্পষ্ট, এবং ত্রুটি সম্পর্কিত তথ্য একটি বিরাট তথ্য জানানো যেতে পারে।

জেএসএন প্রতিক্রিয়ার কথা বলতে গিয়ে আমি এই মামলার জন্য রেল ত্রুটির প্রতিক্রিয়াটিকে মানীকরণ করি tend

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

এই ফর্ম্যাটটি ফর্ম বৈধতার জন্য উপযুক্ত, যা আমি 'ত্রুটি প্রতিবেদনের ত্রুটি'র ক্ষেত্রে সমর্থন করার জন্য সবচেয়ে জটিল ক্ষেত্রে বিবেচনা করি। যদি আপনার ত্রুটির কাঠামো এটি হয় তবে এটি সম্ভবত আপনার ত্রুটি প্রতিবেদন করার সমস্ত প্রয়োজনীয়তা পরিচালনা করবে।


2
আরগগুলির মধ্যে মিথস্ক্রিয়া থেকে উদ্ভূত ত্রুটিগুলি সম্পর্কে কী। অর্থাৎ arg1বৈধ এবং arg2বৈধ, কিন্তু দুই সমন্বয়, নির্দিষ্ট মান পাঠিয়ে বৈধ নয়।
জোনাহ

1
আমি এটা ভেবে দেখব না; সম্পর্কের মালিক বলে মনে হচ্ছে এমন একটি বেছে নিন।
sethcall

অথবা উভয় আর্গ উপর এমনকি ত্রুটি। একজন ব্যবহারকারী হিসাবে, আমি মনে করি যে আমি প্রতিটি ক্ষেত্রের সাথে বিরোধপূর্ণ তা ত্রুটি দেখতে চাই, আমি মনে করি।
13:18

নিস !. সুস্পষ্ট
বর্ণনামূলক

46

200

উঘ ... (309, 400, 403, 409, 415, 422) ... অনেকগুলি উত্তর অনুমান করার, তর্ক করার এবং মানক করার চেষ্টা করছে একটি সফল এইচটিটিপি অনুরোধের জন্য সেরা রিটার্ন কোডটি তবে একটি ব্যর্থ আরআরএসটি কল

HTTP স্থিতি কোড এবং REST স্থিতি কোডগুলি মিশ্রিত করা ভুল

যাইহোক, আমি অনেকগুলি প্রয়োগগুলি সেগুলিকে মিশ্রিত করতে দেখেছি এবং অনেক বিকাশকারী আমার সাথে একমত হতে পারে না।

এইচটিটিপি রিটার্ন কোডগুলি HTTP Requestনিজের সাথে সম্পর্কিত । হাইপারটেক্সট ট্রান্সফার প্রোটোকল অনুরোধটি ব্যবহার করে একটি আরইএসটি কল করা হয় এবং এটি নিজেই অনুরোধ করা আরআরইএসটি পদ্ধতির চেয়ে কম স্তরে কাজ করে। আরআরইএসটি হ'ল একটি ধারণা / পন্থা এবং এর আউটপুট একটি ব্যবসায়িক / যৌক্তিক ফলাফল, যখন এইচটিটিপি রেজাল্ট কোডটি পরিবহন

উদাহরণস্বরূপ, আপনি যখন / ব্যবহারকারীদের / কল করে তখন "404 পাওয়া যায় না" ফিরে আসা, কারণ এর অর্থ হতে পারে:

  • ইউআরআই ভুল (HTTP)
  • কোনও ব্যবহারকারীকে পাওয়া যায়নি (REST)

"403 নিষিদ্ধ / অ্যাক্সেস অস্বীকৃত" এর অর্থ হতে পারে:

  • বিশেষ অনুমতি প্রয়োজন। ব্রাউজারগুলি ব্যবহারকারী / পাসওয়ার্ড জিজ্ঞাসা করে এটি পরিচালনা করতে পারে। (HTTP-)
  • সার্ভারে ভুল অ্যাক্সেস অনুমতি কনফিগার করা হয়েছে। (HTTP-)
  • আপনাকে অনুমোদন দেওয়া দরকার (REST)

এবং তালিকাটি '500 সার্ভার ত্রুটি' (একটি অ্যাপাচি / এনগিনেক্স এইচটিটিপি নিক্ষেপ ত্রুটি বা আরএসটি-তে একটি ব্যবসায় বাধা ত্রুটি) বা অন্যান্য এইচটিটিপি ত্রুটি ইত্যাদি দিয়ে চালিয়ে যেতে পারে ...

কোড থেকে, এটি ব্যর্থতার কারণ, একটি HTTP (পরিবহন) ব্যর্থতা বা একটি REST (যৌক্তিক) ব্যর্থতা কী তা বোঝা শক্ত।

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

এর পরিবর্তে আপনি 200 টি এইচটিপি কোড কিছু বিকল্পের সাথে ফিরে আসতে পারেন:

  • কিছু ভুল হয়ে গেলে JSON ফলাফলটিতে "ত্রুটি" অবজেক্ট
  • খালি JSON অ্যারে / বস্তু যদি কোনও রেকর্ড না পাওয়া যায়
  • আরও ভাল হ্যান্ডলিংয়ের জন্য পূর্ববর্তী বিকল্পগুলির সাথে একত্রে একটি ফল ফলাফল / সাফল্যের পতাকা।

এছাড়াও, কিছু ইন্টারনেট সরবরাহকারী আপনার অনুরোধগুলি বাধা দিতে পারে এবং আপনাকে একটি 404 এইচটিটিপি কোড ফিরিয়ে দিতে পারে। এর অর্থ এই নয় যে আপনার ডেটা পাওয়া যায় নি, তবে এটি পরিবহন স্তরে কিছু ভুল।

উইকি থেকে :

জুলাই 2004 সালে, যুক্তরাজ্যের টেলিকম সরবরাহকারী বিটি গ্রুপ ক্লিনফিড কনটেন্ট ব্লকিং সিস্টেম মোতায়েন করেছে, যা ইন্টারনেট ওয়াচ ফাউন্ডেশন দ্বারা সম্ভাব্য অবৈধ হিসাবে চিহ্নিত সামগ্রীর জন্য কোনও অনুরোধে 404 ত্রুটি প্রদান করে। অন্যান্য আইএসপি একই পরিস্থিতিতে একটি HTTP 403 "নিষিদ্ধ" ত্রুটি প্রদান করে। সেন্সরশিপ গোপন করার উপায় হিসাবে নকল 404 ত্রুটি নিয়োগের অনুশীলন থাইল্যান্ড এবং তিউনিসিয়ায়ও প্রকাশিত হয়েছে। তিউনিসিয়ায়, যেখানে ২০১১ সালের বিপ্লবের আগে সেন্সরশিপ কঠোর ছিল, লোকেরা নকল ৪০৪ ত্রুটির প্রকৃতি সম্পর্কে সচেতন হয়েছিল এবং "অমার্শন ৪০৪" নামে একটি কাল্পনিক চরিত্র তৈরি করেছিলেন, যিনি "অদৃশ্য সেন্সর" উপস্থাপন করেন।

এই জাতীয় কিছু দিয়ে কেবল উত্তর দেবেন না কেন?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

অনুরোধটি যৌক্তিকভাবে ব্যর্থ হলেও, গুগল সর্বদা তাদের জিওকোডিং এপিআই-তে 200 স্ট্যাটাস কোড হিসাবে ফেরত দেয়: https://developers.google.com/maps/docamentation/geocoding/intro#StatusCodes

ফেসবুক সর্বদা সফল এইচটিটিপি অনুরোধের জন্য 200 ফিরিয়ে দেয়, এমনকি যদি REST অনুরোধ ব্যর্থ হয়: https://developers.facebook.com/docs/ راف-api/used-ographic-api/error-handling

এটি সহজ, এইচটিটিপি স্থিতি কোডগুলি এইচটিটিপি অনুরোধের জন্য। REST এপিআই আপনার, আপনার স্থিতি কোডগুলি সংজ্ঞায়িত করুন।


3
আসলে, আরএসটি-র জন্য এইচটিটিপি স্থিতি কোডগুলি রাস্তাটি আরও বিভ্রান্ত করছে: 1) আপনি আপনার বিকাশকারীর টুলবক্সে 4XX দেখতে পাচ্ছেন এবং সার্ভারের কিছু সংবেদনশীল মান ফিরে এসেছে বা আপনার অনুরোধটি প্রক্রিয়াকরণে ব্যর্থ হয়েছে কিনা তা এদিকে তাকিয়ে আপনি বলতে পারবেন না whether এবং তারপরে ২) আপনার সমস্ত ত্রুটি / ব্যতিক্রম / ক্যাচ হ্যান্ডলারের উচিত সার্ভারের প্রতিক্রিয়া হিসাবে কোনটি ফিরে এসেছে (বেশিরভাগ ক্ষেত্রে তারা তা প্রতিটি পরিষেবা কলের জন্য করতে হবে না) এবং বহুবার you) আপনি একই বেতনের ভার পান ( টাইপ) জটিল / নকল কোডের দিকে পরিচালিত সাফল্য এবং ত্রুটি উভয় পথে ... সত্যিই খুব বিভ্রান্তিকর।
szczepanpp

9
এই উত্তরটি এইচটিটিপি প্রোটোকলের মূল শব্দার্থকে বিভ্রান্ত করে তোলে কীভাবে আরটিএসটি কীভাবে এইচটিটিপিকে একটি আর্কিটেকচারাল স্টাইল হিসাবে HTTP ওয়েব-সার্ভিস API গুলি বাস্তবায়নের জন্য পুনরায় উদ্দেশ্য করে। একটি স্থাপত্য শৈলী হিসাবে, আরইএসটি কঠোরভাবে অনুসরণ করার মান নয়, এটি একটি প্রস্তাবিত পদ্ধতির approach বৈধতা ব্যর্থতার জন্য 200 প্রতিক্রিয়া ব্যবহার করা সঠিক বা ভুল নয়, তবে অনুরোধটি সফল হয়েছে বলে প্রতিক্রিয়া জানাতে আপনার ক্লায়েন্টদের বিভ্রান্ত করা হচ্ছে, তবে বাস্তবে বৈধতা ব্যর্থতার কারণে ব্যর্থ হয়েছে, একটি গুরুত্বপূর্ণ বিবরণ যা প্রতিক্রিয়াটির শৃঙ্খলে আবদ্ধ, শব্দার্থক যা বোঝার জন্য ক্লায়েন্টকে বিশ্লেষণ করতে হবে।
কেভিন হুক

5
@ মারকডোর যদি আপনার এপিআই কল ব্যর্থ হয় তবে আপনি 200 টি সাফল্যের সূচক ফিরিয়ে দেন তবে এটি কীভাবে ভাল ধারণা? এটি আপনার API এর গ্রাহকদের কাছে অস্পষ্ট এবং বিভ্রান্তিকর।
কেভিন হুক

3
কেবলমাত্র HTTP বনাম REST ত্রুটিগুলির পৃথকীকরণ নয়, বিভিন্ন কারণে সংশোধন করুন। REST বৈধতার জন্য প্রায়শই আরও উপদ্রব প্রয়োজন। উদাহরণস্বরূপ, রেকর্ড স্বীকৃত তবে অনন্য সূচক লঙ্ঘনের জন্য নকল বনাম হিসাবে প্রত্যাখাত হিসাবে প্রতীকযুক্ত। আপনি একটি ধারাবাহিক রিটার্ন মডেলও চান। .NET BadRequest()পদ্ধতির নিজস্ব রিটার্ন মডেল রয়েছে যা আপনার নিয়মিত রিটার্ন মডেল থেকে পৃথক হবে। এটি পার্স করার একটি দুঃস্বপ্ন। @ কেভিনহুক, আরএসটি-র বৈধতা ত্রুটির জন্য এইচটিটিপি 200 ফিরিয়ে দেওয়া এইরকম বলার মতো, "আমি আপনার বার্তা পেয়েছি, উত্তরটি নেই, এবং কেন তা এখানে" " ফিরে আসা এইচটিটিপি 400 বলে, "আপনি কী বলছেন তা আমি জানি না।"
নীল ল্যাসলেট 15

5
"কারণ গুগল এটি করে, এটি সঠিক হতে হবে" যুক্তি আমার কাছে পাগল .. গুগল বাচ্চাদের বাস্তবায়িত করেছে এমন কিছুকে চ্যালেঞ্জ জানাতে ঠিক আছে। ব্যর্থ বিশ্রামের জন্য এইচটিটিপি 200 ফিরিয়ে দেওয়া এআইপি'র কলারকে বিভ্রান্ত করে তোলে এটি 4XX হওয়া উচিত এবং এটির মধ্যে একটি খুব সুন্দর JSON / XML শরীরে অন্তর্ভুক্ত থাকতে পারে ... একসাথে উন্মাদনা বন্ধ করতে দিন।
জেরিল কুক

43

ডাটাবেসে একটি সদৃশ হওয়া উচিত a 409 CONFLICT

আমি 422 UNPROCESSABLE ENTITYবৈধতা ত্রুটি জন্য ব্যবহার করার পরামর্শ দিচ্ছি ।

আমি এখানে 4XX কোডগুলির দীর্ঘতর ব্যাখ্যা দিচ্ছি ।


6

স্থিতি কোড 304 সংশোধিত নয় এমন নকল অনুরোধের জন্য একটি গ্রহণযোগ্য প্রতিক্রিয়াও জানাবে। এটি If-None-Matchকোনও সত্তা ট্যাগ ব্যবহার করে শিরোনাম প্রক্রিয়াকরণের অনুরূপ ।

আমার মতে, @ পিসকওয়ারের উত্তরটি মূল প্রশ্নের অভিপ্রায় যা আমি বুঝতে পেরেছি তার থেকে আরও স্পষ্ট পছন্দ, তবে আমার কাছে একটি বিকল্পও আছে যা প্রাসঙ্গিক।

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

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


6
এটি আমার বুঝতে পেরেছিল যে 304 ক্যাচিংয়ে সহায়তা করার জন্য জিইটি অপারেশনগুলির উদ্দেশ্যে।
সিনাইস্টেটিক

6

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.