এপিআই ডিজাইন: কংক্রিট বনাম বিমূর্ত পদ্ধতি

25

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

উদাহরণ: একটি সাধারণ "ব্যক্তি অনুসন্ধান" এপিআই এর নকশা। কংক্রিট সংস্করণ হবে

 searchPerson(String name, boolean soundEx,
              String firstName, boolean soundEx,
              String dateOfBirth)

কংক্রিট সংস্করণের পক্ষে লোকেরা বলে:

এপিআই হ'ল স্ব-ডকুমেন্টিং
এটা বোঝা সহজ
এটি যাচাই করা সহজ (সংকলক বা ওয়েবসার্ভিস হিসাবে: স্কিমা বৈধতা)
চুম্বন

আমাদের দলের অন্য গ্রুপের লোকেরা বলবে "এটি কেবল অনুসন্ধানের মানদণ্ডের একটি তালিকা"

searchPerson(List<SearchCriteria> criteria)

সঙ্গে

SearchCritera {
  String parameter,
  String value,
  Map<String, String> options
}

সম্ভবত কিছু গণনার ধরণের "প্যারামিটার" তৈরি করে।

সমর্থকরা বলছেন:

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

পাল্টা যুক্তি হল

বৈধ পরামিতি এবং বৈধ প্যারামিটার সংমিশ্রণ সম্পর্কে প্রচুর ডকুমেন্টেশন
আরও যোগাযোগের প্রচেষ্টা কারণ এটি অন্যান্য দলের পক্ষে বোঝা আরও কঠিন

কোন ভাল অনুশীলন আছে? সাহিত্য?

api web-services api-design

— এরিক
সূত্র

3

পুনরাবৃত্তি "স্ট্রিং প্রথম / নাম, বুলিয়ান soundEx" একটি স্পষ্ট লঙ্ঘন শুষ্ক এবং দাড়ায় যে এই নকশা যে নাম soundEx সঙ্গে বরাবর যেতে বলে আশা করা হচ্ছে মোকাবেলার করতে ব্যর্থ হয়েছে। যে মত সহজ নকশা ভুল সম্মুখীন, এটা আরো পরিশীলিত বিশ্লেষণের সঙ্গে এগিয়ে যেতে হার্ড মতানুযায়ী

— মশা

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

— অ্যারোনআট

@ অ্যারোনটকে এটি নির্দেশ করার জন্য ধন্যবাদ ("বিমূর্ত")। এটি একটি অনুবাদ সমস্যা হতে পারে, জার্মান শব্দগুলির মধ্যে "জেনেরিশ" এখনও আমার কাছে ঠিক আছে। আপনার কাছে "সত্যিকারের মৌলিক প্রশ্ন" কী?

— এরিক

4

@ অ্যারোনট: প্রশ্নটি বিমূর্ত সম্পর্কে নয়। সঠিক সংশোধন হবে "জেনেরিক" এর বিপরীতে "নির্দিষ্ট", "কংক্রিট" নয়।

— জানু হুডেক

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

— ম্যাট ফ্রেইক

18

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

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

— কার্ল বিলেফেল্ট
সূত্র

7

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

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

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

কখনও কখনও, বিমূর্ততা জটিলতা মারাত্মকভাবে হ্রাস করতে সহায়তা করে: আপনি কেবল 3 + 4, 2 + 2 এবং 7 + 6 যুক্ত করার জন্য একটি ক্যালকুলেটর ডিজাইন করলেও এক্স + ওয়াই প্রয়োগ করা (এক্স এবং প্রযুক্তিগতভাবে সম্ভাব্য সীমানা সহ) প্রয়োগ করা আরও সহজ হতে পারে Y, এবং আপনার API এ ADD_3_4 (), ADD_2_2 () এর পরিবর্তে ADD (X, Y) অন্তর্ভুক্ত করুন ...

সব মিলিয়ে একটি বা অন্য উপায় বাছাই করা কেবল প্রযুক্তিগত বিবরণ। আপনার ডকুমেন্টেশনে একটি ঘন ঘন ব্যবহারের ক্ষেত্রে একটি কংক্রিট পদ্ধতিতে বর্ণনা করা উচিত।

আপনি ডেটা স্ট্রাকচার দিকটি যাই করুন না কেন, একটি API সংস্করণের জন্য একটি ক্ষেত্র সরবরাহ করুন।

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

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

— রোমান সুসি
সূত্র

1

আমার ব্যক্তিগত পছন্দটি বিমূর্ত হতে হবে, তবুও আমার সংস্থার নীতিগুলি আমাকে কংক্রিট হিসাবে চিহ্নিত করে। এটাই আমার পক্ষে বিতর্কের সমাপ্তি :)

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

বিরোধী দৃষ্টিভঙ্গি সহ আমার এখানে দুটি বুকমার্ক রয়েছে:

অ্যাবস্ট্রাক্ট ক্লাস পছন্দসই

ইন্টারফেস পছন্দসই

নিজেকে জিজ্ঞাসা করুন: "এআইপিআই কি আমার ব্যবসায়ের প্রয়োজনীয়তা পূরণ করে? সাফল্যের জন্য আমার কি ভাল সংজ্ঞা দেওয়া আছে? এটি কি স্কেল করতে পারে?"। এগুলি অনুসরণ করার পক্ষে সত্যিকারের সাধারণ সেরা অনুশীলনের মতো মনে হয় তবে সত্যই তারা কংক্রিট বনাম জেনেরিকের চেয়ে অনেক বেশি গুরুত্বপূর্ণ।

— gws2
সূত্র

1

আমি বলব না যে একটি বিমূর্ত API অবশ্যই যাচাইকরণ করা আরও কঠিন difficult মানদণ্ডের পরামিতিগুলি যদি যথেষ্ট সহজ এবং একে অপরের মধ্যে সামান্য নির্ভরতা থাকে তবে আপনি পরামিতিগুলি পৃথকভাবে বা অ্যারেতে পাস করলেও এটি খুব বেশি পার্থক্য করে না। আপনার এখনও তাদের সমস্তটি যাচাই করা দরকার। তবে এটি মানদণ্ডের পরামিতিগুলির নকশার উপর নির্ভর করে এবং সেগুলি নিজেরাই।

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

— Pavels
সূত্র

1

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

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

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

— জান হুডেক
সূত্র

1

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

যেমনটি আগে চিহ্নিত করা হয়েছিল - আমি ইন্টারফেসটি পরিবর্তন না করেই পরিবর্তনটি প্রয়োগ বা বাস্তবায়ন বাড়ানোর সুযোগ পছন্দ করি। অন্য অনুসন্ধানের মানদণ্ড যুক্ত করা পরিষেবার সংজ্ঞাতে প্রতিফলিত হবে না।

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

— 0x0me
সূত্র

1

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

ভাল এপিআই

ভুল হওয়া অসম্ভব।
সংকলক / লিঙ্কার আপনাকে এটিকে ভুল হতে দেয় না।
আপনি যদি এটি ভুল হয়ে থাকেন তবে সংকলকটি সতর্ক করবে।
সুস্পষ্ট ব্যবহার হ'ল (সম্ভবত) সঠিকটি।
নামটি আপনাকে এটি কীভাবে ব্যবহার করতে হবে তা বলে।
এটি ঠিক করুন বা এটি সর্বদা রানটাইম এ বিরতি।
সাধারণ সম্মেলন অনুসরণ করুন এবং আপনি এটি সঠিক পাবেন get
ডকুমেন্টেশন পড়ুন এবং আপনি এটি সঠিক পাবেন।
বাস্তবায়ন পড়ুন এবং আপনি এটি সঠিক পাবেন।
সঠিক মেলিং তালিকার থ্রেডটি পড়ুন এবং আপনি এটি সঠিকভাবে পেয়ে যাবেন।

খারাপ এপিআই

মেলিং তালিকার থ্রেডটি পড়ুন এবং আপনি এটি ভুল পেয়ে যাবেন।
বাস্তবায়ন পড়ুন এবং আপনি এটি ভুল পাবেন।
ডকুমেন্টেশন পড়ুন এবং আপনি এটি ভুল পাবেন।
সাধারণ সম্মেলন অনুসরণ করুন এবং আপনি এটি ভুল পাবেন get
এটি সঠিকভাবে করুন এবং এটি কখনও কখনও রানটাইমের সময় ভেঙে যায়।
নামটি আপনাকে কীভাবে এটি ব্যবহার করবেন না তা জানায়।
সুস্পষ্ট ব্যবহার ভুল।
সঠিকভাবে পেলে সংকলক সতর্ক করবে।
সংকলক / লিঙ্কার আপনাকে এটি সঠিকভাবে পেতে দেয় না।
সঠিক হওয়া অসম্ভব।

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

— JensG
সূত্র

0

সাধারণ মানুষের কথায়:

বিমূর্ত পদ্ধতির চারপাশে কংক্রিট পদ্ধতিগুলি তৈরি করার অনুমতি দেওয়ার সুবিধা রয়েছে।
অন্য উপায় কাছাকাছি সত্য নয়

— তুলিনেস কর্ডোভা
সূত্র

ইউডিপিতে আপনার নিজের নির্ভরযোগ্য স্ট্রিমগুলি তৈরি করার অনুমতি দেওয়ার সুবিধা রয়েছে। তাহলে কেন প্রায় সবাই টিসিপি ব্যবহার করছেন?

— এসভিক

বেশিরভাগ ব্যবহারের ক্ষেত্রেও বিবেচনা রয়েছে। কিছু ক্ষেত্রে এত ঘন ঘন প্রয়োজন হতে পারে যে এই কেসগুলিকে বিশেষ করে তোলা সম্ভব।

— রোমান সুসি

0

আপনি প্রসারিত তাহলে SearchCriteriaধারণা একটি সামান্য বিট, এটা আপনি যেমন তৈরি হিসাবে নমনীয়তা দিতে পারে AND, ORইত্যাদি মানদণ্ড। আপনার যদি এই জাতীয় কার্যকারিতা প্রয়োজন হয় তবে এটি আরও ভাল পদ্ধতির হতে পারে।

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

— Uooo
সূত্র

0

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

আপনার ব্যক্তির জন্য অনুসন্ধানের উদাহরণটি কি তিনটি ক্ষেত্রেই প্রয়োজনীয়? যদি তা হয় তবে মাপদণ্ডের তালিকাটি খারাপ কারণ এটি প্রচুর ব্যবহারের জন্য মঞ্জুরি দেয় যা কেবল প্লেইন কাজ করে না। যদি না হয় তবে ব্যবহারকারীর অ প্রয়োজনীয় ইনপুটগুলি নির্দিষ্ট করার প্রয়োজন হয় না। অ্যাড্রেস দ্বারা অনুসন্ধানের সম্ভাব্যতা কীভাবে ভি 2 এ যুক্ত হতে চলেছে? নমনীয় ইন্টারফেস অবিচ্ছিন্ন একের চেয়ে যোগ করা সহজ করে তোলে।

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

— stonemetal
সূত্র

এপিআই ডিজাইন: কংক্রিট বনাম বিমূর্ত পদ্ধতি - সেরা অনুশীলন?