অ্যাপ্লিকেশন স্তরের ইভেন্টগুলি বর্ণনা করতে আমার কি HTTP স্থিতি কোডগুলি ব্যবহার করা উচিত?

Question

বেশ কয়েকটি সার্ভারের সাথে আমি মোকাবিলা করেছি যাতে অনুরোধের জন্য এইচটিটিপি 200 ফিরিয়ে দেবে যে ক্লায়েন্টের শরীরে 'সাফল্য: মিথ্যা' এর মতো কিছু সহ একটি ব্যর্থতা বিবেচনা করা উচিত।

এটি আমার কাছে HTTP কোডগুলির যথাযথ প্রয়োগের মতো বলে মনে হয় না, বিশেষত ব্যর্থ প্রমাণীকরণের ক্ষেত্রে। আমি এইচটিটিপি ত্রুটি কোডগুলি খুব সংক্ষিপ্তভাবে সংক্ষিপ্তসার হিসাবে পড়েছি, '4xx' নির্দেশ করে যে অনুরোধটি পরিবর্তন না হওয়া পর্যন্ত পুনরায় করা উচিত নয়, যখন '5xx' ইঙ্গিত দেয় যে অনুরোধটি বৈধ হতে পারে এবং নাও হতে পারে এবং পুনরায় চেষ্টা করা যেতে পারে তবে এটি ব্যর্থ হয়েছিল। এই ক্ষেত্রে 200: লগইন ব্যর্থ হয়েছে, বা 200: সেই ফাইলটি খুঁজে পায়নি বা 200: অনুমান পরামিতি x, অবশ্যই ভুল বলে মনে হচ্ছে।

অন্যদিকে, আমি যুক্তিটি দেখছিলাম যে '4XX' কেবল অনুরোধের সাথে একটি কাঠামোগত সমস্যা নির্দেশ করতে পারে issue সুতরাং 200 ফিরিয়ে দেওয়া যথাযথ: 401 অননুমোদিতের চেয়ে খারাপ ব্যবহারকারীর / পাসওয়ার্ডের কারণে ক্লায়েন্টকে অনুরোধ করার অনুমতি দেওয়া হয়েছে, তবে এটি ভুল হয়েছে happens এই যুক্তিটি সংক্ষেপে সংক্ষেপে বলা যেতে পারে, যদি সার্ভারটি অনুরোধটি প্রক্রিয়াকরণ করতে এবং আদৌ একটি সংকল্প করতে সক্ষম হয় তবে প্রতিক্রিয়া কোডটি 200 হওয়া উচিত এবং আরও তথ্যের জন্য বডিটি পরীক্ষা করা ক্লায়েন্টের হাতে up

মূলত, এটি পছন্দ করার বিষয় বলে মনে হচ্ছে। তবে এটি অসন্তুষ্টিজনক, সুতরাং যদি কারও কারও কারও কারও কারও কারও কারও কারও কারও সাথে সাথে সাথে এই দৃষ্টান্তগুলির মধ্যে একটি আরও সঠিক হয়, আমি জানতে চাই।

Comments

success: falseইঙ্গিত দেয় যে অনুরোধটি ব্যর্থ হয়েছে এবং আপনি এটি জানেন। এটি একটি 500 হওয়া উচিত your আপনার খারাপ ব্যবহারকারীর নাম / পাসওয়ার্ডের মতো 401 হবে This এটি এতটা অস্পষ্ট নয়।

— পিট

সিএফ স্ট্যাকওভারফ্লো.com

— কাগন ম্যাটসন

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

— রোবট

যখন আমি সত্যিই নিশ্চিত না যে কোনও HTTP স্থিতি ফিরে আসবে তা 418 এর সাথে সর্বদা প্ররোচিত হয় "আমি একটি চাঁচি" "

— জোশপ

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

— রোবং

Answer 1

আকর্ষণীয় প্রশ্ন।

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

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

অ্যাপ্লিকেশন-নির্দিষ্ট প্রবাহগুলি পরিচালনা করার জন্য এইচটিটিপি প্রোটোকলকে পিগিগ্যাক করার চেষ্টা করার ক্ষেত্রে সমস্যাটি হ'ল আপনার দুটি বিকল্পের একটির মধ্যে বাকি রয়েছে: 1) আপনাকে অবশ্যই আপনার অনুরোধ / প্রতিক্রিয়া যুক্তিকে HTTP নিয়মের একটি উপসেট তৈরি করতে হবে; বা 2) আপনার অবশ্যই কিছু নির্দিষ্ট নিয়ম পুনরায় ব্যবহার করতে হবে এবং তারপরে উদ্বেগের বিচ্ছিন্নতা अस्पष्ट হয়ে উঠবে। এটি প্রথমে সুন্দর এবং পরিষ্কার দেখতে পারে তবে আমার মনে হয় আপনার প্রকল্পের বিকাশের সাথে সাথে আফসোস করা শেষ করে দেওয়া ডিজাইন সিদ্ধান্তগুলির মধ্যে এটি একটি।

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

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

Comments

খুব অন্তর্দৃষ্টিপূর্ণ। এখানে সবচেয়ে শক্তিশালী যুক্তি হ'ল HTTP স্থিতি কোড এবং আপনার অ্যাপ্লিকেশনটির ফেরতের মানগুলির মধ্যে (প্রতিবন্ধকতা) অমিল। এটি দীর্ঘকালীন দুঃস্বপ্নে পরিণত হতে পারে। আরও, আমি পরিবহণ (এইচটিটিপি) এবং পে-লোড (অ্যাপ্লিকেশন ডেটা) এর মধ্যে উদ্বেগের বিচ্ছেদকে সর্বাধিক সমর্থন করি। আপনি যদি কোনও পরিষেবা শেষের পয়েন্টের ইউআরএলটি ভুল টাইপ করেন তবে আপনি একটি 404 পাবেন you

আপনি যদি ইউআরএলটি ভুল টাইপ করেন তবে আপনি সঠিক সার্ভারেও শেষ না হয়ে পারেন এবং তারপরেও কিছু ঘটতে পারে।

— gnasher729

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

— Kagan Mattson

আমি রাজী. এইচটিটিপি 200 প্রতিক্রিয়াতে অ্যাপ্লিকেশন-স্তরের ত্রুটিটি প্রতিবেদন করার সাথে কোনও সমস্যা নেই। 200 ইঙ্গিত দেয় যে এইচটিটিপি অনুরোধ / প্রতিক্রিয়া নিজেই সফল হয়েছিল, এর সামগ্রীতে বা অ্যাপ্লিকেশন-স্তরের শব্দার্থতাকে সেই সময়ে আহ্বান করা সম্পর্কে কিছু না বলে।

— মনিকা

Answer 2

এই প্রশ্নটি কিছুটা মতামত ভিত্তিক, তবে উভয় দিক থেকেই।

আমি এটি যেভাবে দেখছি, 200 "নরম ত্রুটিগুলি" পরিবেশন করতে পারে। যখন API এর বিল্ডিংয়ের বিষয়টি আসে আমি এই এবং "হার্ড ত্রুটি" এর মধ্যে পার্থক্য করার চেষ্টা করি।

"নরম ত্রুটি" 200 এর স্ট্যাটাস কোডের সাথে পরিবেশন করা হবে তবে এতে ত্রুটির বর্ণনা এবং এর সাফল্যের স্থিতি থাকবে false। "নরম ত্রুটি" কেবল তখনই ঘটবে যখন ফলাফলটি "প্রত্যাশিত হিসাবে" হবে তবে কঠোর অর্থে সাফল্য নয়।

এটি নোট করা গুরুত্বপূর্ণ যে "সফট ত্রুটিগুলি" প্রয়োগকারীকে আরও ইঙ্গিত দেয়। এর জন্য ত্রুটি সম্পর্কে আরও তথ্য সরবরাহ করা গুরুত্বপূর্ণ যেমন মানব-পঠনযোগ্য ত্রুটি বার্তা এবং / অথবা এমন কোনও কোড যা শেষ ব্যবহারকারীকে প্রতিক্রিয়া সহ সরবরাহ করতে ব্যবহার করা যেতে পারে। এই ত্রুটিগুলি প্রয়োগকারীর (এবং শেষ ব্যবহারকারী) জিনিসগুলির সার্ভারে কী ঘটেছিল সে সম্পর্কে আরও তথ্য সরবরাহ করে ।

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

JSON হিসাবে ফর্ম্যাট উদাহরণ:

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

অন্যদিকে "হার্ড ত্রুটি" , একটি স্থিতি কোডের সাথে পরিবেশন করা হবে যা ত্রুটির জন্য প্রস্তাবিত। ব্যবহারকারী লগ ইন না? - 403 / 401. ত্রুটিযুক্ত ইনপুট? - 400. সার্ভার ত্রুটি? - 50 এক্স ইত্যাদি।

আবার এটি কিছুটা মতামত ভিত্তিক। কিছু লোক সমস্ত ত্রুটিকে সমানভাবে, "ত্রুটিযুক্ত ত্রুটি" হিসাবে সবকিছু করতে চায়। কোন অনুসন্ধান ফলাফল নেই? এটি একটি 404! মুদ্রার অন্যদিকে, কোনও অনুসন্ধানের ফলাফল নেই? - এটি প্রত্যাশা মতো, কোনও ত্রুটি নেই।

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

Comments

আসলে, এপিআই-স্তরে মোটেও ত্রুটি হিসাবে শ্রেণিবদ্ধ করা একটি কৌতূহলী সিদ্ধান্ত। যদিও ক্লায়েন্ট তার বিবেচনার ভিত্তিতে এটিকে ব্যবহারকারী-স্তরে অপ্রত্যাশিত হিসাবে শ্রেণিবদ্ধ করতে পারে।

— Deduplicator

এমন অনেকগুলি বিষয় রয়েছে যাগুলিতে ফ্যাক্টর করতে হবে It এটি সমস্ত এপিআই বাস্তবায়নের উপর নির্ভর করে। এটি আবারও, কিছুটা মতামত ভিত্তিক এবং এপিআই "সাফল্য" এবং / অথবা "ত্রুটি" হিসাবে সংজ্ঞায়িত করে to "success": false-Flag একটি বেশি হয় ইঙ্গিতটি implementer যে কিছু নির্ভর করে। সাধারণত এটি একটি অভ্যন্তরীণ স্থিতি কোড সহ করা উচিত । হয় "code": "NORESULTS"বা একটি সংখ্যাসূচক কোড - এপিআই ফ্যান্সির স্রষ্টা যাই হোক না কেন। এটি বেশিরভাগ ক্ষেত্রেই তাই যে কেউ এপিআই প্রয়োগ করে সে সার্ভারে যা ঘটেছিল সে সম্পর্কে তথ্য কেটে নিতে পারে।

— মর মাউস

Answer 3

একটি এপিআই এর দুটি দিক রয়েছে: এপিআই বাস্তবায়নের প্রচেষ্টা এবং এপিআই সঠিকভাবে ব্যবহার করার জন্য সমস্ত ক্লায়েন্টের প্রচেষ্টা।

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

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

যদি ক্লায়েন্ট "আমাকে সমস্ত রেকর্ডের মতো ..." জিজ্ঞাসা করে এবং শূন্য থাকে, তবে সাফল্য সহ 200 এবং শূন্য রেকর্ডের একটি অ্যারে সম্পূর্ণ উপযুক্ত। আপনি যে কেসগুলি উল্লেখ করেছেন:

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

বিশেষত "প্যারামিটার অনুপস্থিত" - এটি এমন কিছু নয় যা আমি কখনও পরিচালনা করতে পারি । এর অর্থ আমার অনুরোধটি ভুল। যদি আমার অনুরোধটি ভুল হয় তবে আমার সেই ভুল অনুরোধটি ঠিক করার ফ্যালব্যাক নেই - আমি এটি শুরু করার জন্য একটি সঠিক অনুরোধ পাঠাব। এখন আমি এটি পরিচালনা করতে বাধ্য। আমি একটি 200 পেয়েছি এবং যাচাই করতে হবে একটি উত্তর "প্যারামিটার অনুপস্থিত" আছে কিনা। এটা বাজে.

শেষ পর্যন্ত, অনেকগুলি বিভিন্ন পরিস্থিতি পরিচালনা করার জন্য এক ডজন বা দুটি স্থিতি কোড রয়েছে এবং আপনার সেগুলি ব্যবহার করা উচিত।

Comments

কোনও এপিআই-তে সংযোগ করার সময়, কোনও বৈধ শেষের পয়েন্টের সাথে সংযোগ স্থাপন করার সময় আমি ব্যক্তিগতভাবে বরং একটি 'ফাইল খুঁজে পাইনি' তে 200 পেয়ে যাব যেহেতু আমার এইচটিটিপি হ্যান্ডলিংটি তার উপরে থাকা এপিআইটিকে সামঞ্জস্য করে এমন স্তরে রক্তপাত করতে হবে না।

— হোয়াটসাইম

"অনুপস্থিত প্যারামিটার x" 400 টি BAD_REQUEST হওয়া উচিত কারণ এটি ক্লায়েন্টটি কিছু ভুল করছে। যেখানে সার্ভার ভুল কাজ করছে সেগুলির জন্য 500 INTERNAL_SERVER_ERROR সংরক্ষণ করা উচিত। একটি 500 ইঙ্গিত দেয় যে ক্লায়েন্ট আবার চেষ্টা করতে সক্ষম হতে পারে। একটি 400 ইঙ্গিত দেয় যে কেউ যেন ক্লায়েন্টকে ঠিক করতে পারে।

— রোবট

আপনি যদি একটি রেস্টফুল ইন্টারফেস লিখছেন তবে ইউআরএল একটি নির্দিষ্ট বস্তু সনাক্ত করে এবং সুতরাং একটি 404 উপযুক্ত। এটি ধারণাগতভাবে একই /customers/premium/johndoe.jsonগ্রাহককে বোঝায় যা ডাটাবেসে নেই এবং যদি /files/morefiles/customers.htmlকোনও ফাইলটি সিস্টেম সিস্টেমে না দেখায়।

— রোবট

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

— পিট

একটি জিনিস যা আমি উল্লেখ করি নি তা হ'ল আপনি যখন এইচটিটিপি স্থিতি কোডগুলিতে পিগব্যাক অ্যাপ্লিকেশন ত্রুটি করেন, আপনি তথ্য হারাতে পারেন। যদি অ্যাপ্লিকেশনটি কেবল একটি 404 প্রদান করে এবং অন্য কিছুই না, আপনি জানেন না যে এটি আপনার API এ 404 ফেরত দেওয়ার কারণে হয়েছিল, বা সার্ভারটি ফাইলটি খুঁজে পায়নি। এটি আপনার ডিবাগিংয়ে আরও একটি পদক্ষেপ যুক্ত করতে পারে।

— AmadeusDrZaius