সাধারণত আমি মেটাডেটা হিসাবে ফলাফল রেকর্ড সংখ্যা ফিরে আসত। আমি নিশ্চিত নই যে এটি স্বাভাবিক আরএসটি অনুশীলন কিনা, তবে এটি অতিরিক্ত অতিরিক্ত ডেটা নয় এবং এটি খুব সুনির্দিষ্ট। সাধারণত প্রচুর পরিষেবার জন্য পৃষ্ঠা রয়েছে, এটি একবারে বিশাল রেজাল্টটি ফিরিয়ে দেওয়া অবৈধ। ব্যক্তিগতভাবে আমি বিরক্ত নই যখন ছোট ফলাফলের সেটের জন্য পত্রাঙ্কন এসে গেছে .. যদি খালি, প্রত্যাবর্তন number_of_records : 0
এবং বইগুলি খালি তালিকা / অ্যারে হিসাবে books : []
।
{
meta: {
number_of_records : 2,
records_per_page : 10,
page : 0
},
books : [
{id:1},
{id:27}
]
}
সম্পাদনা (কয়েক বছর পরে): মার্টিন উইকম্যানের উত্তর আরও ভাল, কেন তা ব্যাখ্যা করার জন্য এখানে "সংক্ষিপ্ত" রয়েছে।
পৃষ্ঠাগুলি নিয়ে কাজ করার সময় সর্বদা সামগ্রীর সম্ভাবনা মনে রাখবেন বা পরিবর্তনের আদেশ দিন। মত, প্রথম অনুরোধ আসে, 24 ফলাফল, আপনি প্রথমে ফিরে যান 10 এর পরে, "নতুন বই" সন্নিবেশ করা হয়েছে এবং এখন আপনার 25 টি ফলাফল রয়েছে, তবে মূল অনুরোধের সাথে এটি 10 তম স্থানে অর্ডার হবে। যখন প্রথম ব্যবহারকারী দ্বিতীয় পৃষ্ঠার জন্য অনুরোধ করেন, তিনি "নতুন বই" পাবেন না। এই জাতীয় সমস্যাগুলি পরিচালনা করার উপায় রয়েছে যেমন "অনুরোধ আইডি" সরবরাহ করা যা নিম্নলিখিত এপিআই কলগুলির সাথে প্রেরণ করা উচিত, তারপরে "পুরাতন" ফলাফল সেট থেকে পরবর্তী পৃষ্ঠাটি ফিরে আসা, যা কোনওভাবে সংরক্ষণ করা উচিত এবং "অনুরোধ আইডিতে" আবদ্ধ করা উচিত। বিকল্প হ'ল "প্রথম অনুরোধের পর থেকে ফলাফলের তালিকা পরিবর্তিত হয়েছে" এর মতো ক্ষেত্র যুক্ত করা।
সাধারণত, আপনি যদি পারেন তবে অতিরিক্ত চেষ্টা করার চেষ্টা করুন এবং পৃষ্ঠা-রচনা এড়ান। পৃষ্ঠাগুলি অতিরিক্ত রাজ্য যা রূপান্তরিত হতে পারে এবং এই জাতীয় পরিবর্তনগুলি ট্র্যাক করা ত্রুটি প্রবণ, আরও বেশি কারণ সার্ভার এবং ক্লায়েন্ট উভয়ই এটি পরিচালনা করতে পারে।
আপনার যদি একবারে প্রক্রিয়া করার জন্য খুব বেশি ডেটা থাকে , তবে সেই তালিকার কিছু অংশের জন্য সমস্ত ফলাফল এবং বিশদ সহ "আইডি তালিকা" ফেরত বিবেচনা করুন এবং সংস্থার জন্য মাল্টি_জেট / get_by_id_list API কল সরবরাহ করুন।