আমার কি অজানা প্যারামিটারের অনুমতি দেওয়া উচিত?

Question

আমি একটি RESTful এপিআই ডিজাইন করছি এবং শিরোনাম সমস্যার মুখোমুখি, স্পষ্টতার জন্য পুনরায় সেট করা:

যদি কোনও ক্লায়েন্ট একটি অপরিচিত পরামিতি প্রেরণ করে তবে আমার কী দ্রুত ব্যর্থ হওয়া উচিত? উদাহরণ স্বরূপ,

http://example.com/api/foo?bar=true&paula=bean

উপরের দিকে, barএকটি বৈধ প্যারামিটার তবে paulaএপিআই দ্বারা নির্দিষ্ট করা হয়নি। আমি কি

• ত্রুটির ক্লায়েন্টকে সতর্ক করুন
• দ্রুত ব্যর্থ
• বাদ দাও

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

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

আমার যুক্তি কি বোধগম্য? এই জাতীয় জিনিসগুলির জন্য কোনও গ্রহণযোগ্য অনুশীলন আছে?

Comments

একটি ছোট পরীক্ষার উপর ভিত্তি করে, আমি পরীক্ষিত সমস্ত সাইটগুলি কেবলমাত্র আমি সরবরাহ করা সেই অজানা প্যারামিটারগুলি উপেক্ষা করে।

— বার্ট ভ্যান ইনজেন শেহেনো

পুনঃটুইট করুন gen এটি ওয়েব পৃষ্ঠাগুলির পক্ষে ঠিক আছে তবে আমি মনে করি না যে এটি কোনও আসল এপিআই

— রথ

একটি উদ্বেগ সামনের সামঞ্জস্য। যদি অজানা যুক্তি উপেক্ষা করা হয় তবে ভবিষ্যতের সংস্করণগুলিতে সেগুলি এমনভাবে ব্যবহার করা সম্ভব যাতে ক্লায়েন্টরা নতুন এপিআইতে প্রোগ্রাম করতে পারে এবং এখনও পুরানো সার্ভারগুলিতে যুক্তিসঙ্গত আচরণ পেতে পারে।

— 12

@ ওয়ালপেন এটি একটি আকর্ষণীয় বিষয়। সংস্করণযুক্ত ইউআরএল api/v1ইত্যাদি ব্যবহার করা এটির যত্ন নেবে তবে এটি এখনও বর্ধিত আপডেটের অনুমতি দেয় না। +1

— রথ

সেখানে আপনি বাস্তব লাইভ দৃষ্টিকোণ থেকে কিছু সমর্থক এবং সন্ধান করতে পারেন: কঠোর পরামিতি এবং আপনার এপিআই ।

— রেমেক আম্রোজিযাক

Answer 1

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

অবৈধ প্যারামগুলিকে অগ্রাহ্য করা আরও বেশি ব্যবহারিক পদ্ধতির হতে পারে তবে আপনি যেভাবেই যান, আচরণটি ভাল করে নথিভুক্ত করতে ভুলবেন না।

Comments

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

— স্টেপান স্টেপানভ

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

— রাবারডাক

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

— স্টেপান স্টেপনোভ

Answer 2

আপনি যদি সর্বজনীন এপিআই করেন (বা এপিআই যা অন্য দলের দ্বারা ব্যবহৃত হবে), আমি @ রাবারডাকের পরামর্শ অনুসারে ফিরতি ত্রুটির প্রস্তাব দেব।

যদি আপনার এপিআইটি কেবলমাত্র আপনার দলের অভ্যন্তরে গ্রাস করা হয় (বা কেবল নিজেরাই) তবে অতিরিক্ত ক্ষেত্রগুলি উপেক্ষা করা আরও সহজ (যেমন কম কোড এবং করা সহজ)।