কোন বস্তুর আইটেমের মোট সংখ্যা ফেরত দেওয়ার জন্য সবচেয়ে ভাল RESTful পদ্ধতি কী?


139

আমি জড়িত একটি বৃহত সামাজিক নেটওয়ার্কিং ওয়েবসাইটের জন্য একটি REST API পরিষেবা বিকাশ করছি So এখন পর্যন্ত এটি দুর্দান্ত কাজ করছে। আমি ইস্যু করতে পারে GET, POST, PUTএবং DELETEবস্তুর URL গুলিতে অনুরোধ এবং আমার ডেটা প্রভাবিত। তবে এই তথ্যটি পৃষ্ঠাযুক্ত (একসাথে 30 টি ফলাফলের মধ্যে সীমাবদ্ধ)।

যাইহোক, আমার এপিআই এর মাধ্যমে সদস্যদের মোট সংখ্যা, পাওয়ার সবচেয়ে ভাল উপায় কী হবে?

বর্তমানে, আমি নিম্নলিখিতগুলির মতো একটি ইউআরএল কাঠামোতে অনুরোধগুলি প্রকাশ করি:

  • / এপিআই / সদস্যগণ members সদস্যদের একটি তালিকা পুনরায় চালু করুন (উপরে উল্লিখিত হিসাবে একসাথে 30)
  • / এপিআই / সদস্য / 1 - ব্যবহৃত অনুরোধ পদ্ধতির উপর নির্ভর করে একক সদস্যকে প্রভাবিত করে

আমার প্রশ্ন হ'ল: আমি কীভাবে তার পরে আমার আবেদনের মোট সদস্য সংখ্যা পেতে অনুরূপ ইউআরএল কাঠামো ব্যবহার করব? স্পষ্টতই কেবল idক্ষেত্রটির জন্য অনুরোধ করা (ফেসবুকের গ্রাফ এপিআইয়ের অনুরূপ) এবং ফলাফল গণনা অকার্যকর হবে কেবলমাত্র 30 টি ফলাফলের টুকরো কেবল ফিরে আসবে।


উত্তর:


84

/ এপিআই / ব্যবহারকারীদের প্রতিক্রিয়া পৃষ্ঠাযুক্ত এবং কেবল 30, রেকর্ডগুলি ফেরত থাকলেও প্রতিক্রিয়াতে আপনাকে রেকর্ডের মোট সংখ্যা এবং পৃষ্ঠার আকারের মতো অন্যান্য প্রাসঙ্গিক তথ্য, পৃষ্ঠা নম্বর / অফসেট ইত্যাদি অন্তর্ভুক্ত করা থেকে বিরত রাখার মতো কিছুই নেই etc ।

স্ট্যাকওভারফ্লো এপিআই সেই একই ডিজাইনের একটি ভাল উদাহরণ। ব্যবহারকারী পদ্ধতির জন্য ডকুমেন্টেশন এখানে রয়েছে - https://api.stackexchange.com/docs/users


3
+1: আনার সীমাটি যদি আদৌ আরোপিত হতে চলেছে তবে অবশ্যই এটি করা সবচেয়ে বিশ্রামযুক্ত কাজ।
ডোনাল ফেলো

2
@bzim আপনি জানেন যে আনতে পরবর্তী পৃষ্ঠা রয়েছে কারণ সেখানে rel = "পরের" সাথে একটি লিঙ্ক রয়েছে।
ড্যারেল মিলার

4
@ ডোনাল "পরবর্তী" রিয়েল
ড্যারেল মিলার

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

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

74

আমি এই জাতীয় প্রাসঙ্গিক তথ্যের জন্য HTTP শিরোনাম ব্যবহার পছন্দ করি।

উপাদানগুলির মোট সংখ্যার জন্য আমি X-total-countশিরোলেখ ব্যবহার করি ।
পরবর্তী, পূর্ববর্তী পৃষ্ঠাগুলি ইত্যাদির লিঙ্কগুলির জন্য আমি HTTP Linkশিরোনাম ব্যবহার করি :
http://www.w3.org/wiki/LinkHeader

গিথুব এটি একইভাবে করেন: https://developer.github.com/v3/# পৃষ্ঠা ination

আমার মতে এটি পরিষ্কার, কারণ আপনি যখন হাইপারলিংকগুলি (যেমন বাইনারি, ছবি) সমর্থন করেন না এমন সামগ্রী ফেরৎ পাঠান তখন এটি ব্যবহার করা যায়।


5
আরএফসি 6648 স্ট্রিং সহ আনস্ট্যান্ডার্ডাইজড প্যারামিটারগুলির নাম উপস্থাপনের কনভেনশনটিকে হ্রাস করে X-
জেডগ

70

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

শিরোলেখ

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

মোট গণনা সহ পেজিং সম্পর্কিত তথ্য ফেরত দিতে বুনোয় ব্যবহৃত (স্ট্যান্ডার্ড এবং কাস্টম) শিরোনাম রয়েছে।

এক্স-মোট গোনা

X-Total-Count: 234

এটি বন্যের মধ্যে পাওয়া কিছু এপিআইতে ব্যবহৃত হয় । এছাড়াও রয়েছে NPM প্যাকেজ যেমন লুপব্যাক এই হেডারের জন্য সমর্থন যোগ করার জন্য। কিছু নিবন্ধগুলি এই শিরোনামটিও সেট করার পরামর্শ দেয়।

এটি প্রায়শই Linkশিরোলেখের সাথে একত্রে ব্যবহৃত হয় , যা পেজিংয়ের জন্য বেশ ভাল সমাধান, তবে মোট গণনা সম্পর্কিত তথ্য অভাবী।

লিংক

Link: </TheBook/chapter2>;
      rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
      </TheBook/chapter4>;
      rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

আমি এই বিষয় উপর অনেক পড়া থেকে বোধ, যে সাধারণ ঐক্যমত্য ব্যবহার করা Linkহেডার ব্যবহার ক্লায়েন্ট লিঙ্ক সংখ্যা লাগিয়ে প্রদান rel=next, rel=previousইত্যাদি এই সঙ্গে সমস্যা এটি কতগুলি মোট রেকর্ডের তথ্য আছে অভাব আছে, যা হয় কেন অনেকগুলি API গুলি এটিকে X-Total-Countশিরোলেখের সাথে একত্রিত করে ।

বিকল্পভাবে, কিছু এপিআই এবং যেমন জসনএপি মানক, Linkফর্ম্যাটটি ব্যবহার করে তবে শিরোনামের পরিবর্তে প্রতিক্রিয়ার খামে তথ্য যুক্ত করুন। এটি প্রকৃত ডেটা নিজেই অ্যাক্সেস করার জটিলতা ব্যয় করে (একটি খাম যোগ করে) মেটাডেটা অ্যাক্সেসকে সহজ করে তোলে (এবং মোট গণনা তথ্য যুক্ত করার জন্য একটি জায়গা তৈরি করে)।

বিষয়বস্তু-বিন্যাস

Content-Range: items 0-49/234

রেঞ্জের শিরোনাম নামে একটি ব্লগ নিবন্ধ দ্বারা প্রচারিত , আমি আপনাকে (পৃষ্ঠার জন্য) বেছে নিই! । পৃষ্ঠাগুলি জন্য লেখক Rangeএবং Content-Rangeশিরোনাম ব্যবহার করার জন্য একটি শক্তিশালী কেস তৈরি করে । আমরা যখন মনোযোগ দিয়ে পড়ুন বোঝায় যা RFC এই হেডার উপর, আমরা যে বাইটের রেঞ্জ পরেও তাদের অর্থ ব্যাপ্ত আসলে বোঝায় যা RFC পূর্বাভাস পাওয়া হয় এবং স্পষ্টভাবে অনুমোদিত হয়। পরিবর্তে এর প্রসঙ্গে ব্যবহার করা হলে , রেঞ্জের শিরোনামটি আমাদের উভয়কে নির্দিষ্ট আইটেমের নির্দিষ্ট পরিসরের অনুরোধ করার জন্য একটি উপায় দেয় এবং প্রতিক্রিয়া আইটেমগুলির সাথে সম্পর্কিত মোট ফলাফলের পরিসীমা নির্দেশ করে। এই শিরোনামটি মোট সংখ্যাটি দেখানোর জন্য দুর্দান্ত উপায় দেয়। এবং এটি সত্যিকারের মান যা বেশিরভাগ ম্যাপিং একের পর এক পেজিংয়ের জন্য। এটি বন্যগুলিতেও ব্যবহৃত হয় itemsbytes

খাম

আমাদের প্রিয় প্রশ্নোত্তর ওয়েবসাইটের একটি সহ অনেকগুলি এপিআই, একটি খাম , ডেটাটির চারপাশে একটি মোড়ক ব্যবহার করে যা ডেটা সম্পর্কে মেটা তথ্য যুক্ত করতে ব্যবহৃত হয়। এছাড়াও, OData এবং JsonApi মান উভয় একটি প্রতিক্রিয়া খাম ব্যবহার করুন।

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

পৃথক পয়েন্ট

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

আরও চিন্তা

আমাদের কেবল প্রতিক্রিয়া সম্পর্কিত পেজিং মেটা তথ্য যোগাযোগ করতে হবে না, তবে ক্লায়েন্টকে নির্দিষ্ট পৃষ্ঠাগুলি / রেঞ্জগুলির জন্য অনুরোধ করার অনুমতি দেবে। সুসংগত সমাধানের সাথে শেষ পর্যন্ত এই দিকটিও দেখতে আকর্ষণীয়। এখানেও আমরা শিরোলেখগুলি ব্যবহার করতে পারি ( Rangeশিরোনামটি খুব উপযুক্ত বলে মনে হয়), বা কোয়েরি প্যারামিটারের মতো অন্যান্য প্রক্রিয়া। কিছু লোক ফলাফলের পৃষ্ঠাগুলিকে পৃথক সংস্থান হিসাবে চিকিত্সার পক্ষে পরামর্শ দেয়, যা কিছু ব্যবহারের ক্ষেত্রে বোধগম্য হতে পারে (যেমন, /books/231/pages/52আমি শিরোনামকে সমর্থন করার পাশাপাশি ঘন ঘন ব্যবহৃত অনুরোধ পরামিতি যেমন pagesize, page[size]এবং limitইত্যাদি নির্বাচন করে শেষ করেছি Range(এবং অনুরোধ প্যারামিটার হিসাবে যেমন).


আমি বিশেষত Rangeশিরোনাম সম্পর্কে আগ্রহী ছিলাম , তবে আমি পর্যাপ্ত প্রমাণের সন্ধান করতে পারি নি যে bytesপরিসরের ধরণ হিসাবে পৃথক কিছু ব্যবহার করা বৈধ।
ভিজিওএন

2
আমি মনে করি আরএফসির ১৪.৫ অনুচ্ছেদে সুস্পষ্ট প্রমাণ পাওয়া যাবে : acceptable-ranges = 1#range-unit | "none"আমি মনে করি এই সূত্রটি স্পষ্টভাবে অন্যান্য পরিসরের ইউনিটগুলির জন্য জায়গা ছেড়ে দেয় bytes, যদিও অনুমানটি কেবলমাত্র এটিই সংজ্ঞায়িত করে bytes
স্টিজন ডি উইট

24

বিকল্প যখন আপনার আসল আইটেম প্রয়োজন হয় না

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

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

/api/members?metaonly=true
/api/members?includeitems=0

বা অনুরূপ কিছু ...


10
শিরোনামে এই তথ্য এম্বেড করার সুবিধা রয়েছে যে আপনি কেবল গণনা পাওয়ার জন্য একটি হেড অনুরোধ করতে পারেন।
felixfbecker

1
@ ফেলিক্সফাবেকার ঠিকঠাকভাবে, চাকাটি পুনর্বিবেচনার জন্য এবং বিভিন্ন ধরণের বিভিন্ন প্রক্রিয়াযুক্ত
এপিআইগুলিকে ছড়িয়ে দেওয়ার

1
@ ইরালপবি হুইলটি পুনর্নবীকরণ এবং এপিআইগুলিকে বিশৃঙ্খলা করার জন্য ধন্যবাদ !? শিরোনাম HTTP- এ গতিযুক্ত। metaonlyবা includeitemsহয় না।
felixfbecker

2
@ ফেলিক্সফাবেকার কেবল "হুবহু" আপনার জন্য বোঝানো হয়েছিল, বাকিটি ওপি-র জন্য। বিভ্রান্তির জন্য দুঃখিত.
এরালপবি

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

23

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

(অথবা, আপনি যদি এন্ডপয়েন্ট থেকে শেষ পয়েন্ট পর্যন্ত নিয়ন্ত্রিত পরিবেশে থাকেন তবে আপনি একটি কাস্টম এইচটিটিপি ক্রিয়া ব্যবহার করতে পারেন যেমন COUNT))


4
"কাস্টম HTTP শিরোনাম"? এটি কিছুটা অবাক হওয়ার শিরোনামের অধীনে চলে আসবে, যা ঘুরেফিরে আমার মনে হয় একটি রেস্টস্টুল এপিআই হওয়া উচিত। শেষ পর্যন্ত, এটি উদ্বেগজনক হওয়া উচিত।
ডোনাল ফেলো

21
@ ডোনাল আমি জানি। তবে ইতিমধ্যে সমস্ত ভাল উত্তর নেওয়া হয়েছিল। :(
bzlm

1
আমিও জানি, তবে কখনও কখনও আপনি অন্য ব্যক্তিকে উত্তরটি দেওয়ার সুযোগ পান। বা অন্যভাবে আপনার অবদানকে আরও উন্নত করুন যেমন অন্যের চেয়ে কেন এটি সর্বোত্তম উপায়ে করা উচিত তার বিশদ বিবরণ।
ডোনাল ফেলো

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

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

11

আমি এটির জন্য শিরোনাম যুক্ত করার পরামর্শ দেব, যেমন:

HTTP/1.1 200

Pagination-Count: 100
Pagination-Page: 5
Pagination-Limit: 20
Content-Type: application/json

[
  {
    "id": 10,
    "name": "shirt",
    "color": "red",
    "price": "$23"
  },
  {
    "id": 11,
    "name": "shirt",
    "color": "blue",
    "price": "$25"
  }
]

বিস্তারিত জানার জন্য দেখুন:

https://github.com/adnan-kamili/rest-api-response-format

সোয়াগার ফাইলের জন্য:

https://github.com/adnan-kamili/swagger-response-template


7

"এক্স -" হিসাবে - উপসর্গটি অবচয় করা হয়েছিল। (দেখুন: https://tools.ietf.org/html/rfc6648 )

পৃষ্ঠাগুলি রেঞ্জের মানচিত্রের জন্য আমরা "স্বীকৃতি-রেঞ্জগুলি" সেরা বাজি হিসাবে পেয়েছি: https://tools.ietf.org/html/rfc7233#section-2.3 "রেঞ্জ ইউনিটগুলি" হয় "বাইটস" বা " টোকেন". উভয়ই কাস্টম ডেটা ধরণের প্রতিনিধিত্ব করে না। (দেখুন: https://tools.ietf.org/html/rfc7233#section-4.2 ) এখনও বলা হয়েছে যে

HTTP / 1.1 বাস্তবায়ন মেই অন্যান্য ইউনিট ব্যবহার করে নির্দিষ্ট রেঞ্জ উপেক্ষা করে।

যা সূচিত করে: কাস্টম রেঞ্জ ইউনিটগুলি ব্যবহার করা প্রোটোকলের বিরুদ্ধে নয়, তবে এটি এড়ানো হতে পারে।

এইভাবে, আমাদেরকে "সদস্যদের" বা ইউনিট প্রকারের যাই হোক না কেন গ্রহণের সীমা নির্ধারণ করতে হবে we এবং তদতিরিক্ত, কন্টেন্ট-রেঞ্জকে বর্তমান সীমাতেও সেট করে। (দেখুন: https://www.w3.org/Potocols/rfc2616/rfc2616-sec3.html#sec3.12 )

যেভাবেই হোক, আমি 200 এর পরিবর্তে 206 প্রেরণের জন্য আরএফসি 7233 ( https://tools.ietf.org/html/rfc7233# পৃষ্ঠা -8 ) এর সুপারিশকে আঁকড়ে ধরছি :

পূর্ববর্তী সমস্ত শর্ত যদি সত্য হয়, সার্ভার
লক্ষ্য সংস্থানটির জন্য রেঞ্জের শিরোলেখ ক্ষেত্রটিকে সমর্থন করে এবং নির্দিষ্ট রেঞ্জ (গুলি)
বৈধ এবং সন্তোষজনক (বিভাগ ২.১-তে বর্ণিত), সার্ভারটি
একটি 206 (আংশিক সামগ্রী) প্রতিক্রিয়া প্রেরণ করবে বিভাগ 4 এ বর্ণিত হিসাবে
অনুরোধযোগ্য সন্তোষজনক
রেঞ্জের সাথে সামঞ্জস্যপূর্ণ এমন এক বা একাধিক আংশিক উপস্থাপনা সম্বলিত পে-লোড সহ

সুতরাং, ফলস্বরূপ, আমাদের নিম্নলিখিত HTTP শিরোলেখ ক্ষেত্রগুলি থাকবে:

আংশিক সামগ্রীর জন্য:

206 Partial Content
Accept-Ranges: members
Content-Range: members 0-20/100

সম্পূর্ণ সামগ্রীর জন্য:

200 OK
Accept-Ranges: members
Content-Range: members 0-20/20

3

এটিকে যুক্ত করা সবচেয়ে সহজ বলে মনে হচ্ছে

GET
/api/members/count

এবং সদস্যদের মোট গণনা ফিরিয়ে দিন


11
ভালো বুদ্ধি নই. আপনি ক্লায়েন্টদের তাদের পৃষ্ঠাগুলিতে পৃষ্ঠাগুলি তৈরির জন্য 2 অনুরোধ করতে বাধ্য হন। প্রথমে সংস্থানগুলির তালিকা পেতে এবং দ্বিতীয়টি মোট গণনা করার জন্য request
জেকিস

আমি মনে করি এটি ভাল পদ্ধতির ... আপনি জসন হিসাবে কেবলমাত্র ফলাফলের তালিকা এবং সংগ্রহের ক্লায়েন্ট সাইড চেক আকারেও ফিরে আসতে পারেন সুতরাং এই জাতীয় ঘটনাটি বোকামির উদাহরণ ... তাছাড়া আপনি / এপিআই / সদস্য / গণনা এবং তারপরে / এপিআই করতে পারেন / সদস্য? অফসেট = 10 এবং সীমা = 20
মাইচা জিয়োব্রো

1
এছাড়াও মনে রাখবেন যে প্রচুর ধরণের পৃষ্ঠার জন্য কোনও গণনার প্রয়োজন নেই (যেমন অসীম স্ক্রোল) - যখন ক্লায়েন্টের প্রয়োজন নাও পারে তখন এটি কেন গণনা করুন
tofarr

2

একটি নতুন সমাপ্তি বিন্দু> / এপিআই / সদস্য / গণনা সম্পর্কে যা কেবলমাত্র সদস্যদের কল করে ount অ্যাকাউন্ট () এবং ফলাফলটি দেয়


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

2

কখনও কখনও ফ্রেমওয়ার্কগুলি (যেমন $ রিসোর্স / অ্যাঙ্গুলারজেএস) এর জন্য ক্যোয়ারির ফলাফল হিসাবে একটি অ্যারের প্রয়োজন হয় এবং আপনার প্রতিক্রিয়া হেইডার্সে {count:10,items:[...]}আমি "গণনা" সঞ্চয় করি না এমন ক্ষেত্রে সত্যিই আপনার প্রতিক্রিয়া থাকতে পারে না ।

পিএস আসলে আপনি এটি $ রিসোর্স / অ্যাঙ্গুলারজেএস দিয়ে করতে পারেন তবে এটির জন্য কিছু টুইট দরকার।


এই টুইটগুলি কি? : তারা এই এক মত প্রশ্নে সহায়ক হবে stackoverflow.com/questions/19140017/...
JBCP

কৌনিকটি ক্যোয়ারী ফলাফল হিসাবে একটি অ্যারের প্রয়োজনীয়তা রাখে না, আপনাকে কেবল বিকল্প সামগ্রীর সম্পত্তি সহ আপনার সংস্থানটি কনফিগার করতে হবে:isArray: false|true
রামি বেকেরাস


-1

পৃষ্ঠায়িত ডেটার জন্য অনুরোধ করার সময়, আপনি পৃষ্ঠাটির আকারটি স্পষ্ট করে বলতে পারেন (সুস্পষ্ট পৃষ্ঠার আকারের প্যারামিটার মান বা ডিফল্ট পৃষ্ঠার আকারের মান দ্বারা) আপনি জানেন যে প্রতিক্রিয়াতে আপনি সমস্ত ডেটা পেয়েছেন কিনা। প্রতিক্রিয়াতে যখন কোনও পৃষ্ঠার আকারের চেয়ে কম ডেটা থাকে তখন আপনি পুরো ডেটা পেয়ে যান। যখন একটি পূর্ণ পৃষ্ঠা ফিরে আসে, আপনাকে আবার অন্য পৃষ্ঠার জন্য জিজ্ঞাসা করতে হবে।

আমার কাউন্টের জন্য পৃথক সমাপ্তি (বা প্যারামিটার গণনার সাথে একই শেষ পয়েন্ট) পছন্দ হয় prefer কারণ আপনি সঠিকভাবে আরম্ভ করা অগ্রগতি বার দেখিয়ে দীর্ঘ / সময় গ্রহণের প্রক্রিয়াটির জন্য শেষ ব্যবহারকারী প্রস্তুত করতে পারেন।

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

<data>
  <originalRequest>
    <filter/>
    <filter/>
  </originalReqeust>
  <totalRecordCount/>
  <pageSize/>
  <offset/>
  <list>
     <item/>
     <item/>
  </list>
</data>

আমার দম্পতি সুতরাং, নির্দিষ্ট করার সময় প্রতিক্রিয়াটিতে কেবল মেটাডেটা থাকে।

শেষবিন্দু? ফিল্টার = মান

<data>
  <count/>
  <list>
    <item/>
    ...
  </list>
</data>

শেষবিন্দু? ফিল্টার = মান & countOnly সত্য =

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