একটি সাধারণ ব্যর্থ অনুরোধের জন্য উপযুক্ত HTTP স্থিতি কোড প্রতিক্রিয়া কী (ত্রুটি নয়)?

109

আমি একটি RESTful এপিআই তৈরি করছি যা সঞ্চিত ক্রেডিট কার্ড ব্যবহার করে অর্ডার স্থাপন সহ বেশ কয়েকটি ব্যবহারকারীর ইন্টারঅ্যাকশন প্রক্রিয়া করবে।

একটি সফল অর্ডারের ক্ষেত্রে, আমি 200 ওকে ফিরিয়ে দিচ্ছি, এবং সেই ক্ষেত্রে যেখানে আদেশের অনুরোধটি ত্রুটিযুক্ত বা অবৈধ I'm আমি 400 খারাপ অনুরোধটি ফিরিয়ে দিচ্ছি। তবে অর্ডারের প্রকৃত প্রক্রিয়াকরণের সময় যদি কোনও সমস্যা হয় তবে আমি কী ফিরিয়ে আনব?

ক্লায়েন্ট POSTS ব্যবহারকারীর সংস্থার জন্য সার্ভারে আদেশ দেয়। ব্যবহারকারীর অস্তিত্ব না থাকলে, 404 পাওয়া যায় না ফিরে আসে।
অর্ডার বিন্যাস এবং তথ্য যাচাই করা হয়। বৈধ না হলে 400 খারাপ অনুরোধটি ফেরত দেওয়া হবে।
অর্ডার প্রক্রিয়া করা হয়। যদি অর্ডারটি সফল হয়, একটি 201 তৈরি করা অর্ডারের জন্য ফিরে আসে। যদি কোনও অপ্রত্যাশিত ত্রুটি দেখা দেয় তবে একটি 500 সার্ভার ত্রুটি ফিরে আসে।

শেষ পদক্ষেপটি হ'ল সমস্যা - যদি অন্য কোনও কারণে আদেশটি না পূর্ণ হয় তবে আমি কী ফিরিয়ে দেব? সম্ভাব্য পরিস্থিতিতে অন্তর্ভুক্ত থাকতে পারে:

পণ্য বিক্রি হয়
ব্যবহারকারীর সর্বাধিক অর্ডার সীমাতে পৌঁছেছে
ক্রেডিট কার্ড লেনদেন ব্যর্থতা (অপর্যাপ্ত তহবিল, ইত্যাদি)

এটি 400 বা 500 জনের পক্ষে উপযুক্ত বলে মনে হয় না anything আরও ভাল কোড না থাকলে আমি এটিকে 400 হিসাবে দেখতে পাচ্ছিলাম - ব্যবসায়ের নিয়ম অনুসারে অনুরোধটি অবৈধ। এটি ঠিক সঠিক বলে মনে হচ্ছে না।

সম্পাদনা: একই বিষয়ের এই বিদ্যমান আলোচনাটিও খুঁজে পেয়েছি । উত্তরগুলির সমস্ত উত্তর এই ধরণের লঙ্ঘনের জন্য স্থিতি কোডগুলি ব্যবহার করে বলে মনে হচ্ছে, 400, 409 বা 422 এক্সটেনশন ব্যবহারের মধ্যে কিছু আলোচনা রয়েছে।

http rest http-status-codes

— Raelshark
সূত্র

8

বৈধতা ত্রুটির জন্য আমি '422 অপ্রসারণযোগ্য সত্তা' পছন্দ করি। এবং এটি আপনার উপরের উদাহরণগুলির জন্য ব্যবহার করবে, প্রকৃত ব্যবসায়িক সমস্যার সাথে প্রতিক্রিয়াতে একটি বার্তা অন্তর্ভুক্ত করুন "পণ্যটি বিক্রি হয়ে গেছে" এবং ক্লায়েন্টের প্রতিক্রিয়াটির ভিত্তিতে যদি ক্লায়েন্টটি প্রোগ্রামগতভাবে বিভিন্ন সিদ্ধান্ত নেওয়ার প্রয়োজন হয় তবে

— বাড়ি 9

422-এ যাওয়ার আগে, আপনি ওয়েবডিএভি ক্ষমতাগুলি সমর্থন করেন কিনা তা বিবেচনা করুন

— এমবিথ এমবিথ

90

আপনার ব্যবসায়ের নিয়মের জন্য 400 ব্যবহার করা উচিত। অর্ডার গৃহীত না হলে 2xx ফেরত দেবেন না। এইচটিটিপি একটি অ্যাপ্লিকেশন প্রোটোকল, এটি কখনও ভুলে যাবেন না। আপনি যদি 2XX ফেরত দেন তবে ক্লায়েন্ট ধরে নিতে পারে অর্ডারটি গ্রহণ করা হয়েছিল, আপনি শরীরে যে কোনও তথ্যই প্রেরণ করেন নি।

থেকে RESTful ওয়েব পরিষেবা Cookbook :

কিছু সাধারণ পরিষেবা যা কিছু ওয়েব পরিষেবা করে তা হ'ল একটি স্ট্যাটাস কোডটি ফিরিয়ে আনা যা সাফল্যকে প্রতিফলিত করে (200 থেকে 206 এবং 300 থেকে 307 পর্যন্ত স্ট্যাটাস কোড) তবে একটি বার্তা শৃঙ্খলা অন্তর্ভুক্ত করে যা ত্রুটির শর্তটি বর্ণনা করে। এটি করার ফলে এইচটিটিপি-সচেতন সফ্টওয়্যার ত্রুটি সনাক্ত করতে বাধা দেয়। উদাহরণস্বরূপ, একটি ক্যাশে এটি সফল প্রতিক্রিয়া হিসাবে সঞ্চয় করবে এবং পরবর্তী ক্লায়েন্টদের কাছে এটি সরবরাহ করবে এমনকি যখন ক্লায়েন্টরা সফল অনুরোধ করতে সক্ষম হয়।

4xx এবং 5xx এর মধ্যে সিদ্ধান্ত নেওয়ার জন্য আমি এটি ছেড়ে দেব, তবে আপনার একটি ত্রুটি স্থিতির কোড ব্যবহার করা উচিত।

— ম্যাক্স টোরো
সূত্র

1

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

— রায়েলশর্ক

এটাই সত্যি.

— তরুণ হিউন ইয়ু

2

আপনার অর্থ কী, 'আপনার ব্যবসায়ের বিধিগুলির জন্য 4XX ব্যবহার করা উচিত'?

— ইয়াওয়ার

28

ক্লায়েন্ট যদি ত্রুটিটি ঘটাতে অনুরোধটি পরিবর্তন করতে পারে তবে আপনার ক্লায়েন্ট ত্রুটির জন্য 4xx ব্যবহার করা উচিত। এমন একটি সার্ভার ত্রুটির জন্য 5XX ব্যবহার করুন যা ক্লায়েন্ট সত্যই চারপাশে কাজ করতে পারে না।

বিক্রি হওয়া পণ্যটি একটি সার্ভার ত্রুটি হবে। ত্রুটিটি পেতে ক্লায়েন্টটি কিছু ফ্যাশনে অনুরোধটি পরিবর্তন করতে পারে না। আপনি অন্য পণ্যতে স্যুইচ করতে পারেন কিন্তু এটি কি নতুন অনুরোধ হবে না?

ব্যবহারকারীর সর্বাধিক অর্ডার সীমাতে পৌঁছে যাওয়াও একটি সার্ভার ত্রুটি। ক্লায়েন্ট কিছুই করতে পারে না এই ত্রুটিটি কাজ করে।

ক্রেডিট কার্ড লেনদেন ব্যর্থতা একটি ক্লায়েন্ট ত্রুটি হতে পারে। ত্রুটিটি সমাধানের জন্য ক্লায়েন্টটি ভিন্ন অর্থ প্রদানের পদ্ধতি বা ক্রেডিট কার্ড নম্বর দিয়ে অনুরোধটি পুনরায় জমা দিতে পারে।

— পল মরগান
সূত্র

6

যদি অর্ডার সীমাটি পৌঁছে যায়, তবে ক্লায়েন্ট কি ব্যবহারকারীকে সেই বিষয়ে সতর্ক না করে তাদের যথাযথভাবে তাদের অনুরোধটি পরিবর্তন করতে দেওয়া উচিত? এটি 4XX ত্রুটির মতো মনে হচ্ছে। একই পণ্য বিক্রি হয়ে যায়। 5X ত্রুটিগুলি ত্রুটিগুলির উদ্দেশ্যে করা হয় যা কোনওভাবে সিস্টেম ভেঙে যাওয়ার কারণে ঘটে থাকে, কোনও ব্যবসায়ের নিয়ম দ্বারা অনুমোদিত নয় এমন কোনও ক্রিয়াকলাপের জন্য নয়।

— carlin.scott

7

আমি উপরের মন্তব্যে একমত 5xx ত্রুটিগুলি যখন সার্ভারে সমস্যা হয় তখনই হয়। ব্যবসায়িক বিধিগুলির জন্য 4X ত্রুটি।

— Merc

21

ত্রুটির ধরণ:

4×× Client Error

ভুল সংকেত:

422 Unprocessable Entity

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

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

https://httpstatuses.com/422

— stamster
সূত্র

16

আমি জানি এই প্রশ্নটি পুরানো, তবে আমি আজ একই প্রশ্নটি নিয়ে এসেছি। যদি আমার ব্যবহারকারীর ক্রেডিট শেষ না হয় তবে আমার REST এপিআইয়ের কোন স্ট্যাটাস কোডটি ফিরে আসবে?

আমি ঝুঁকির দিকে ঝোঁক 402 Payment Required:

উইকিপিডিয়া অনুসারে :

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

তারা অবশ্যই তা করে :

PAYMENT_REQUIRED (402)

বিকাশকারী দ্বারা নির্ধারিত একটি দৈনিক বাজেটের সীমা পৌঁছে গেছে।

অনুরোধ করা অপারেশনে কোটার অনুমতি দেওয়ার চেয়ে আরও বেশি সংস্থান প্রয়োজন। কার্যক্রমটি সম্পূর্ণ করার জন্য অর্থ প্রদানের প্রয়োজন required

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

— বেঞ্জামিন
সূত্র

এটি সর্বাধিক সুচিন্তিত এবং যৌক্তিক উত্তর।

— জিটিডোরভ

5

কীভাবে 424 Failed Dependency? অনুমান এটি বর্ণনা করে:

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

তবে এই সংজ্ঞাটিও রয়েছে :

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

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

আমি যতদূর দেখতে পাচ্ছি, "অ্যাকশন" বেশ বিস্তৃত শব্দ এবং অপর্যাপ্ত স্টক, অপর্যাপ্ত creditণ বা গুদাম পার্টি নাইট সহ বিভিন্ন পরিস্থিতিতে ব্যবহার করা যেতে পারে।

অন্য বিকল্প হতে পারে 422 Unprocessable Entity:

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

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

স্টকের বাইরে থাকা কোনও আইটেমটির জন্য অনুরোধ করার চেষ্টা করা বা আপনার যখন অপ্রত্যাশিত .ণ রয়েছে তখন শব্দার্থক স্তরে ভুল হিসাবে বিবেচিত হতে পারে।

মোজডেভ বলেছেন যে এটি ক্লায়েন্টের পক্ষে একটি ভুল নির্দেশ করে, বিশেষত: ক্লায়েন্টকে কোনও পরিবর্তন ছাড়াই এই অনুরোধটি পুনরাবৃত্তি করা উচিত নয়।

ইনপুট বৈধতা ব্যর্থ হলে লুপব্যাক 4 422 ব্যবহার করে ।

যুক্তিযুক্তভাবে, অপর্যাপ্ত স্টক বা গুদাম পার্টি নাইট অস্থায়ী রাজ্য হিসাবে বিবেচনা করা যেতে পারে, তাই অনুরোধটি পরে আবার চেষ্টা করা যেতে পারে। এই পরিস্থিতি দ্বারা সূচিত করা যেতে পারে503 Service Unavailable

অস্থায়ী ওভারলোড বা নির্ধারিত রক্ষণাবেক্ষণের কারণে সার্ভারটি বর্তমানে অনুরোধটি পরিচালনা করতে অক্ষম, যা সম্ভবত কিছুটা বিলম্বের পরে অপসারণ করা হবে।

অনুরোধটি পুনরায় চেষ্টা করার আগে ক্লায়েন্টের জন্য অপেক্ষা করার উপযুক্ত পরিমাণের পরামর্শ দেওয়ার জন্য সার্ভারটি পুনরায় চেষ্টা করার পরে শিরোনাম ক্ষেত্রটি প্রেরণ করতে পারে।

— joeytwiddle
সূত্র

এগুলির কোনওটিই কোনও অর্থ প্রদানের সাথে সম্পর্কিত নয়। আমি আগের উত্তর থেকে 402 নিয়ে যাচ্ছি!

— জিটিডোরভ

2

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

আসুন আমরা সমস্ত প্যারামিটারগুলি সঠিক বলে রাখি এবং আমরা ধরা যাক আমরা অনুরোধের মধ্যে ব্যবহারকারীর অ্যাকাউন্ট নম্বরটি পাস করছি।

সুতরাং অনুরোধ এখন আর খারাপ অনুরোধ নয়, সার্ভারটি অনুরোধটি গ্রহণ করতে সক্ষম। তবে এখন এটি উপলব্ধ নতুন তথ্যের উপর ভিত্তি করে অনুরোধটি পূরণ করতে অস্বীকার করছে যা হ'ল - অ্যাকাউন্টে পর্যাপ্ত পরিমাণের ভারসাম্য নেই।

আমি প্রস্তাব দেব যে আমাদের 403 ব্যবহার করা উচিত সেই পরিস্থিতিগুলিতে উপযুক্ত ত্রুটি বার্তা সহ।

অন্যান্য সম্ভাব্য ত্রুটি কোড 409 বিবাদ হতে পারে। তবে এটি সেই পরিস্থিতিতে ব্যবহৃত হয় যেখানে সংস্থানটি সামঞ্জস্যপূর্ণ অবস্থায় থাকে।

— রাজেন্দ্র সায়নী
সূত্র

-1

আমি 406 নিয়ে যাই Not Acceptable।

এখানে একটি 4XX তালিকা রয়েছে:

const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418;                                               // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421;                                         // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422;                                        // RFC4918
const HTTP_LOCKED = 423;                                                      // RFC4918
const HTTP_FAILED_DEPENDENCY = 424;                                           // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425;   // RFC2817
const HTTP_UPGRADE_REQUIRED = 426;                                            // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428;                                       // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429;                                           // RFC6585

— মাহমুদ জাল্ট
সূত্র

8

স্থিতি কোড 406 এর নাম নিজেই সঠিক লাগতে পারে, তবে আপনাকে সচেতন হওয়া দরকার যে প্রতিটি স্থিতির কোডের একটি অনুমোদিত পাঠ্য বিবরণ থাকে। স্থিতি কোড 406 এর বিবরণটি হাতের কাছে থাকা ক্ষেত্রে উপযুক্ত নয় । উদাহরণস্বরূপ, httpstatuses.com/406 দেখুন ।

— জিরো 3

1

@ জিরো 3 সঠিক, এই কোডটির অর্থ প্রতিক্রিয়া প্রকারটি গ্রহণযোগ্য নয়, যেমন ক্লায়েন্টের কাছ থেকে প্রেরিত অ্যাকসেপ্ট শিরোনাম এবং শেষ পয়েন্ট দ্বারা প্রেরিত মিডিয়া টাইপ (গুলি) এর মধ্যে একটি মিল নেই যেমন, অ্যাপ্লিকেশন / জেসন বনাম পাঠ্য / সরল

— গ্রেগর