এপিআই পৃষ্ঠাগুলি সেরা অনুশীলন

288

আমি যে পৃষ্ঠাগুলি তৈরি করছি তার সাথে অদ্ভুত প্রান্তের কেস পরিচালনা করতে কিছু সহায়তা চাই।

অনেকগুলি এপিআই-এর মতো এটিরও বড় ফলাফল রয়েছে। যদি আপনি জিজ্ঞাসা / foos করেন তবে আপনি ১০০ টি ফলাফল (যেমন foo # 1-100), এবং / foos? পৃষ্ঠা = 2 এর লিঙ্ক পাবেন যা foo # 101-200 এ ফিরে আসবে।

দুর্ভাগ্যক্রমে, যদি foo # 10 এপিআই গ্রাহকরা পরবর্তী ক্যোয়ারী তৈরি করার আগে সেট করা ডেটা থেকে মুছে ফেলা হয়, / foos? পৃষ্ঠা = 2 অফসেটটি 100 দ্বারা প্রেরণ এবং foos # 102-201 এ ফিরে আসবে।

এটি এপিআই গ্রাহকদের জন্য সমস্যা, যারা সমস্ত নকলগুলি টানতে চেষ্টা করছেন - তারা foo # 101 পাবেন না।

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

rest  pagination  api-design 
— 2arrs2ells
সূত্র
1
এখানে সমস্যা কি? আমার কাছে ঠিক আছে, উভয় উপায়েই ব্যবহারকারী 100 টি আইটেম পাবেন।
— নারকোজ
2
আমি এই একই সমস্যার মুখোমুখি হয়েছি এবং এর সমাধান খুঁজছি। আফাইক, প্রতিটি পৃষ্ঠা যদি একটি নতুন কোয়েরি কার্যকর করে তবে এটি সম্পাদন করার পক্ষে সত্যিকারের কোনও দৃ solid় গ্যারান্টিযুক্ত ব্যবস্থা নেই। আমি যে সমাধান করতে পারি তার মধ্যে কেবলমাত্র সমাধানটি হ'ল একটি সক্রিয় অধিবেশন রাখুন, এবং ফলাফলটি সার্ভারের পাশে রেখে দিন এবং প্রতিটি পৃষ্ঠার জন্য নতুন অনুসন্ধানগুলি সম্পাদন করার পরিবর্তে কেবলমাত্র পরবর্তী রেকর্ডগুলির সেটটি ধরে ফেলুন।
— জেরি ডজ
31
টুইটার কীভাবে এই dev.twitter.com/rest/public/timelines
— java_geek
1
@ জাভা_জেক কিভাবে_আইডি প্যারামিটার আপডেট হয়? টুইটার ওয়েবপৃষ্ঠায় মনে হয় যেহেতু তারা উভয় অনুরোধ অনুরোধ করছে কারণ যেহেতু_আইডির জন্য একই মান দিয়ে। আমি ভাবছি এটি কখন আপডেট হবে যাতে নতুন টুইটগুলি যুক্ত করা হলে সেগুলির জন্য অ্যাকাউন্ট করা যায়?
— পেটার
1
@ পিতর যেহেতু_আইডি প্যারামিটারটি API এর গ্রাহক দ্বারা আপডেট করা দরকার। যদি আপনি দেখতে পান, তবে উদাহরণটি ক্লায়েন্টদের প্রক্রিয়াকরণের টুইটগুলি বোঝায়
— java_geek

উত্তর:

175

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

আপনি কোয়েরি / foos যখন আপনি 100 ফলাফল পাবেন। আপনার এপিআই এর পরে এমন কিছু ফেরত দেওয়া উচিত (জেএসওন ধরে নিচ্ছেন, তবে যদি এটি এক্সএমএল প্রয়োজন হয় তবে একই নীতি অনুসরণ করা যেতে পারে):

{
    "data" : [
        {  data item 1 with all relevant fields    },
        {  data item 2   },
        ...
        {  data item 100 }
    ],
    "paging":  {
        "previous":  "http://api.example.com/foo?since=TIMESTAMP1" 
        "next":  "http://api.example.com/foo?since=TIMESTAMP2"
    }

}

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

তালিকার সর্বশেষ ডেটা আইটেমটি ব্যবহার করে টাইমস্ট্যাম্পটি গতিশীলভাবে নির্ধারণ করা যেতে পারে। এটি ফেসবুক তার গ্রাফ এপিআইতে কীভাবে প্যাগিনেট করে তা কমবেশি বলে মনে হচ্ছে (আমি উপরে যে ফর্ম্যাটটি দিয়েছি তা পৃষ্ঠাতে লিঙ্কগুলি দেখতে নীচে স্ক্রোল করুন)।

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

— ramblinjan
সূত্র
29
টাইমস্ট্যাম্পগুলি অনন্য হওয়ার গ্যারান্টিযুক্ত নয়। অর্থাৎ একই টাইমস্ট্যাম্প দিয়ে একাধিক সংস্থান তৈরি করা যেতে পারে। সুতরাং এই পদ্ধতির খারাপ দিক রয়েছে যা পরবর্তী পৃষ্ঠাটি, বর্তমান পৃষ্ঠা থেকে শেষ (কয়েক?) এন্ট্রিগুলি পুনরাবৃত্তি করতে পারে।
— রুবেল
4
@ প্রমত্তা আসলে, ডাটাবেস বাস্তবায়নের উপর নির্ভর করে একটি টাইমস্ট্যাম্প অনন্য হওয়ার গ্যারান্টিযুক্ত ।
— রমব্লিজান
2
@ জন্ডজোরজেনসেন আপনার লিঙ্কটি থেকে: "টাইমস্ট্যাম্প ডেটা টাইপটি কেবল একটি বাড়ানো সংখ্যা এবং কোনও তারিখ বা একটি সময় সংরক্ষণ করে না ... ... এসকিউএল সার্ভার ২০০৮ এবং তারপরে , টাইমস্ট্যাম্প টাইপটির নাম পরিবর্তন করে রোভার্সন করা হয়েছে , সম্ভবত এটির আরও ভাল প্রতিফলিত করার জন্য উদ্দেশ্য এবং মান। " সুতরাং এখানে কোন প্রমাণ নেই যে টাইমস্ট্যাম্পগুলি (যেগুলিতে আসলে একটি সময়ের মূল্য থাকে) অনন্য।
— নোলান অ্যামি
3
@ জন্ডজোরজেনসেন আমি আপনার প্রস্তাবটি পছন্দ করি, তবে কি আপনার উত্স লিঙ্কগুলিতে কোনও ধরণের তথ্যের প্রয়োজন হবে না, তাই আমরা জানি আমরা যদি পূর্ববর্তী বা পরবর্তী যাই? Sth এর মতো: "পূর্ববর্তী": " api.example.com/foo?before=TIMESTAMP " "পরের": " api.example.com/foo?since=TIMESTAMP2 " আমরা টাইমস্ট্যাম্পের পরিবর্তে আমাদের সিকোয়েন্স আইডিগুলিও ব্যবহার করব। আপনি কি তাতে কোনও সমস্যা দেখছেন?
— দীর্ঘজীবী
5
আর একটি অনুরূপ বিকল্পটি আরএফসি 5988 (বিভাগ 5) এ উল্লিখিত লিংক শিরোলেখ ক্ষেত্রটি ব্যবহার করা হবে: সরঞ্জাম.এইটিএফ.আর.এফএইচটিএমএল
— অ্যান্টনি এফ
28

আপনার বেশ কয়েকটি সমস্যা আছে।

প্রথমত, আপনি উদাহরণটি দিয়েছেন যা আপনি উদ্ধৃত করেছেন।

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

আপনি যদি আসল ডেটা সেটটি স্ন্যাপশ্যাটিং না করে থাকেন তবে এটি কেবল জীবনের সত্য।

আপনি ব্যবহারকারীকে একটি স্পষ্ট স্ন্যাপশট তৈরি করতে পারেন:

POST /createquery
filter.firstName=Bob&filter.lastName=Eubanks

ফলাফল:

HTTP/1.1 301 Here's your query
Location: http://www.example.org/query/12345

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

যদি ব্যবহারের ক্ষেত্রে সহজেই আপনার ব্যবহারকারীরা সমস্ত ডেটা চান (এবং প্রয়োজন) হন তবে আপনি কেবল তাদের এটিকে দিতে পারেন:

GET /query/12345?all=true

এবং কেবল পুরো কিটটি প্রেরণ করুন।

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

আপনি যদি পৃষ্ঠা আঁকেন তবে আপনার কিছু কী দ্বারা ডেটা বাছাই করতে হবে। ইউপিএল ক্লায়েন্টদের ইউআরএলতে পূর্ববর্তী সংগ্রহের শেষ উপাদানটির চাবিটি কেন অন্তর্ভুক্ত করা উচিত নয় এবং WHEREআপনার এসকিউএল কোয়েরিতে (বা আপনি যদি এসকিউএল ব্যবহার করছেন না তবে সমমানের কিছু) একটি ধারা যুক্ত করুন যাতে এটি কেবল সেই উপাদানগুলিকেই ফেরত দেয় যা কী এই মানটির চেয়ে বড়?

— kamilk
সূত্র
4
এটি কোনও খারাপ পরামর্শ নয়, তবে কেবলমাত্র একটি মান অনুসারে বাছাই করার অর্থ এই নয় যে এটি একটি 'কী', অর্থাৎ অনন্য।
— ক্রিস ময়ূর 15
যথাযথভাবে। যেমন আমার ক্ষেত্রে, সাজানোর ক্ষেত্রটি একটি তারিখ হিসাবে ঘটে এবং এটি অনন্য থেকে দূরে।
— শনি থিরু
19

আপনার সার্ভারের পার্শ্ব যুক্তির উপর নির্ভর করে দুটি পন্থা থাকতে পারে।

পন্থা 1: যখন সার্ভার বস্তুর অবস্থা পরিচালনা করতে যথেষ্ট স্মার্ট না হয়।

আপনি সমস্ত ক্যাশেড রেকর্ড অনন্য আইডি সার্ভারে প্রেরণ করতে পারেন, উদাহরণস্বরূপ ["id1", "id2", "id3", "id4", "id5", "id6", "id7", "id8", "id9", "আইডি 10"] এবং আপনি নতুন রেকর্ডের জন্য অনুরোধ করছেন কিনা তা জানতে একটি বুলিয়ান প্যারামিটার (রিফ্রেশ করতে টানুন) বা পুরানো রেকর্ডগুলি (আরও লোড করুন)।

আপনার বিভাজককে নতুন রেকর্ডগুলি (রিফ্রেশ করার জন্য টানার মাধ্যমে আরও রেকর্ড বা নতুন রেকর্ড লোড করা) পাশাপাশি ["id1", "id2", "id3", "id4", "id5", " id6 "," id7 "," id8 "," id9 "," id10 "]।

উদাহরণ: - আপনি যদি আরও বেশি বোঝার জন্য অনুরোধ করছেন তবে আপনার অনুরোধটি এর মতো দেখতে হবে: -

{
        "isRefresh" : false,
        "cached" : ["id1","id2","id3","id4","id5","id6","id7","id8","id9","id10"]
}

এখন ধরা যাক আপনি পুরানো রেকর্ডগুলির জন্য অনুরোধ করছেন (আরও বেশি লোড করুন) এবং ধরুন যে "আইডি 2" রেকর্ডটি কেউ আপডেট করেছে এবং "আইডি 5" এবং "আইডি 8" রেকর্ডগুলি সার্ভার থেকে মুছে ফেলা হয়েছে তবে আপনার সার্ভারের প্রতিক্রিয়াটি এর মতো দেখতে হবে: -

{
        "records" : [
{"id" :"id2","more_key":"updated_value"},
{"id" :"id11","more_key":"more_value"},
{"id" :"id12","more_key":"more_value"},
{"id" :"id13","more_key":"more_value"},
{"id" :"id14","more_key":"more_value"},
{"id" :"id15","more_key":"more_value"},
{"id" :"id16","more_key":"more_value"},
{"id" :"id17","more_key":"more_value"},
{"id" :"id18","more_key":"more_value"},
{"id" :"id19","more_key":"more_value"},
{"id" :"id20","more_key":"more_value"}],
        "deleted" : ["id5","id8"]
}

তবে এই ক্ষেত্রে যদি আপনি প্রচুর স্থানীয় ক্যাশেড রেকর্ড হিসাবে ধরে রাখেন 500, তবে আপনার অনুরোধের স্ট্রিংটি এর চেয়ে দীর্ঘ হবে: -

{
        "isRefresh" : false,
        "cached" : ["id1","id2","id3","id4","id5","id6","id7","id8","id9","id10",………,"id500"]//Too long request
}

পদ্ধতির 2: যখন সার্ভারটি তারিখ অনুসারে অবজেক্টের অবস্থা পরিচালনা করতে যথেষ্ট স্মার্ট থাকে।

আপনি প্রথম রেকর্ডের ID এবং শেষ রেকর্ড এবং পূর্ববর্তী অনুরোধের সময় প্রেরণ করতে পারেন। আপনি প্রচুর পরিমাণে ক্যাশেড রেকর্ড থাকলেও আপনার অনুরোধটি সর্বদা ছোট

উদাহরণ: - আপনি যদি আরও বেশি বোঝার জন্য অনুরোধ করছেন তবে আপনার অনুরোধটি এর মতো দেখতে হবে: -

{
        "isRefresh" : false,
        "firstId" : "id1",
        "lastId" : "id10",
        "last_request_time" : 1421748005
}

আপনার সার্ভারটি মুছে ফেলা রেকর্ডগুলির আইডিটি ফিরিয়ে আনার জন্য দায়বদ্ধ যা শেষ_আপনিবাদ_সময়ের পরে মুছে ফেলা হয়েছে এবং পাশাপাশি "আইডি 1" এবং "আইডি 10" এর মধ্যে লাস্ট_রেকুস্ট_টাইমের পরে আপডেট হওয়া রেকর্ডটি ফিরিয়ে দেয়।

{
        "records" : [
{"id" :"id2","more_key":"updated_value"},
{"id" :"id11","more_key":"more_value"},
{"id" :"id12","more_key":"more_value"},
{"id" :"id13","more_key":"more_value"},
{"id" :"id14","more_key":"more_value"},
{"id" :"id15","more_key":"more_value"},
{"id" :"id16","more_key":"more_value"},
{"id" :"id17","more_key":"more_value"},
{"id" :"id18","more_key":"more_value"},
{"id" :"id19","more_key":"more_value"},
{"id" :"id20","more_key":"more_value"}],
        "deleted" : ["id5","id8"]
}

রিফ্রেশ করতে টানুন: -

এখানে চিত্র বর্ণনা লিখুন

আর ঢুকাও

এখানে চিত্র বর্ণনা লিখুন

— মোহাম্মদ ইফতেখার কুরশী
সূত্র
14

সেরা অনুশীলনগুলি খুঁজে পাওয়া শক্ত হতে পারে যেহেতু APIs সহ বেশিরভাগ সিস্টেমে এই দৃশ্যের জন্য উপযুক্ত নয়, কারণ এটি একটি চূড়ান্ত প্রান্ত, বা তারা সাধারণত রেকর্ডগুলি মুছে দেয় না (ফেসবুক, টুইটার)। ফেসবুক আসলে বলেছে যে পৃষ্ঠাগুলির পরে ফিল্টারিংয়ের কারণে প্রতিটি "পৃষ্ঠায়" অনুরোধ করা ফলাফলের সংখ্যা নাও থাকতে পারে। https://developers.facebook.com/blog/post/478/

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

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

— ব্রেন্ট বাইসলে
সূত্র
2
এটি কোনও গ্রহণযোগ্য সমাধান নয়। এটি যথেষ্ট সময় এবং স্মৃতি ব্যয় করে। অনুরোধ করা ডেটা সহ সমস্ত মুছে ফেলা ডেটা স্মৃতিতে রাখা দরকার যা একই ব্যবহারকারী যদি আরও প্রবেশের জন্য অনুরোধ না করে তবে এগুলি ব্যবহার করা যেতে পারে না।
— দীপক গার্গ
3
আমি একমত নই কেবল অনন্য আইডি রাখলে মোটেও খুব বেশি স্মৃতি ব্যবহার হয় না। আপনি কেবল "অধিবেশন" এর জন্য, অনির্দিষ্টকালের জন্য ডেটা ধরে রাখতে পারবেন না। এটি মেমক্যাসের সাহায্যে সহজ, কেবল মেয়াদ শেষ হওয়ার সময়কাল (অর্থাত 10 মিনিট) সেট করুন।
— ব্রেন্ট বাইসলে
মেমরিটি নেটওয়ার্ক / সিপিইউ গতির চেয়ে সস্তা। সুতরাং যদি কোনও পৃষ্ঠা তৈরি করা খুব ব্যয়বহুল (নেটওয়ার্কের দিক থেকে বা সিপিইউ নিবিড়), তবে ক্যাশে ফলাফলগুলি একটি বৈধ পন্থা @ প্রদীপগার
— ইউ আভালোস
9

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

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

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

আমার ক্ষেত্রে আমি পুরো তথ্য (প্রাথমিকভাবে রেফারেন্স সারণী ডেটা) পাওয়ার জন্য কিছু স্পষ্টতই কিছু API কলকে মনোনীত করি। আপনি এই এপিআইগুলিও সুরক্ষিত করতে পারেন যাতে এটি আপনার সিস্টেমে ক্ষতি না করে।

— আর্কিমিডস ট্রাজানো
সূত্র
8

বিকল্প একটি: একটি টাইমস্ট্যাম্প সহ কীসেট প্যাসেজেশন

আপনি উল্লেখ করেছেন অফসেট পৃষ্ঠাগুলিটির ত্রুটিগুলি এড়াতে আপনি কীসেট ভিত্তিক পৃষ্ঠাগুলি ব্যবহার করতে পারেন। সাধারণত, সত্তাগুলির একটি টাইমস্ট্যাম্প থাকে যা তাদের তৈরি বা পরিবর্তনের সময় উল্লেখ করে। এই টাইমস্ট্যাম্পটি পৃষ্ঠাবদ্ধকরণের জন্য ব্যবহার করা যেতে পারে: পরবর্তী অনুরোধের জন্য ক্যোয়ারী প্যারামিটার হিসাবে শেষ উপাদানটির টাইমস্ট্যাম্পটি কেবল পাস করুন। সার্ভার, ঘুরে, টাইমস্ট্যাম্পটি ফিল্টার মাপদণ্ড হিসাবে ব্যবহার করে (যেমন WHERE modificationDate >= receivedTimestampParameter)

{
    "elements": [
        {"data": "data", "modificationDate": 1512757070}
        {"data": "data", "modificationDate": 1512757071}
        {"data": "data", "modificationDate": 1512757072}
    ],
    "pagination": {
        "lastModificationDate": 1512757072,
        "nextPage": "https://domain.de/api/elements?modifiedSince=1512757072"
    }
}

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

  • যখন কোনও এক পৃষ্ঠার সমস্ত উপাদানগুলির একই টাইমস্ট্যাম্প থাকে তখন আপনি অন্তহীন লুপগুলিতে দৌড়াতে পারেন।
  • যখন একই টাইমস্ট্যাম্প সহ উপাদানগুলি দুটি পৃষ্ঠকে ওভারল্যাপ করে তখন আপনি ক্লায়েন্টকে একাধিকবার বিতরণ করতে পারেন।

পৃষ্ঠার আকার বাড়াতে এবং মিলিসেকেন্ড যথার্থতার সাথে টাইমস্ট্যাম্প ব্যবহার করে আপনি সেগুলি কমগুলি তৈরি করতে পারেন।

বিকল্প বি: একটি ধারাবাহিকতা টোকেন সহ প্রসারিত কীসেট পৃষ্ঠা ination

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

{
    "elements": [
        {"data": "data", "modificationDate": 1512757070}
        {"data": "data", "modificationDate": 1512757072}
        {"data": "data", "modificationDate": 1512757072}
    ],
    "pagination": {
        "continuationToken": "1512757072_2",
        "nextPage": "https://domain.de/api/elements?continuationToken=1512757072_2"
    }
}

টোকেন "1512757072_2" পৃষ্ঠার শেষ উপাদানটিকে নির্দেশ করে এবং জানিয়েছে "ক্লায়েন্ট ইতিমধ্যে 1512757072 টাইমস্ট্যাম্প সহ দ্বিতীয় উপাদান পেয়েছে"। এইভাবে, সার্ভারটি কোথায় চালিয়ে যেতে হবে তা জানে।

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

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

— phauer
সূত্র
4

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

এখন, আপনি যদি চান যে পৃষ্ঠাগুলি 2 সর্বদা 101 থেকে শুরু হওয়া উচিত এবং 200 এ শেষ হওয়া উচিত, তবে আপনাকে পৃষ্ঠাটিতে প্রবেশের সংখ্যাটি পরিবর্তনশীল হিসাবে অবশ্যই তৈরি করতে হবে, কারণ সেগুলি মুছে ফেলার বিষয়।

আপনার নীচের সিউডোকোডের মতো কিছু করা উচিত:

page_max = 100
def get_page_results(page_no) :

    start = (page_no - 1) * page_max + 1
    end = page_no * page_max

    return fetch_results_by_id_between(start, end)
— mickeymoon
সূত্র
1
আমি রাজী. রেকর্ড নম্বর দ্বারা ক্যোয়ারী (যা বিশ্বাসযোগ্য নয়) আপনার আইডি দিয়ে জিজ্ঞাসা করা উচিত। আপনার আইডি (x, মি) এর সাথে "আইডির মাধ্যমে সকার্টেড আইডি> এক্স" এর অর্থ আপনার ক্যোয়ারি (x, মি) পরিবর্তন করুন, তারপরে আপনি কেবলমাত্র আগের ক্যোয়ারী ফলাফল থেকে সর্বাধিক আইডিতে এক্স সেট করতে পারবেন।
— জন হেন্কেল
সত্য, হয় আইডির উপর বাছাই করুন বা আপনার যদি ক্রিয়েশন_ডেট ইত্যাদির মতো বাছাই করার জন্য কিছু কংক্রিট ব্যবসায়ের ক্ষেত্র রয়েছে
— মিকিউমুন
4

কামিলকের এই উত্তরে কেবল যুক্ত করতে: https://www.stackoverflow.com/a/13905589

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

সেখানে স্ট্যাটিক প্রতিটি পর্যায়ে ধনাত্মকতা এবং নেতিবাচক ব্যাখ্যাগুলি বাড়ানোর সাথে সাথে স্ল্যাক কীভাবে তার এপিআই-র পৃষ্ঠাটি বিকশিত করেছিল সে সম্পর্কে একটি দুর্দান্ত নিবন্ধটি পেয়েছে: https://slack.engineering/evolving-api-pagination-at-slack-1c1f644f8e12

— শুভম শ্রীবাস্তব
সূত্র
3

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

আপনার কোনও আইটেম মোছার উদাহরণ হ'ল আইসবার্গের কেবলমাত্র টিপ। আপনি যদি ফিল্টার করছেন color=blueতবে কেউ যদি অনুরোধের মধ্যে আইটেমের রঙ পরিবর্তন করে? পেজড পদ্ধতিতে সমস্ত আইটেম নির্ভরযোগ্যভাবে আনতে অসম্ভব ... যদি না ... আমরা পুনর্বিবেচনার ইতিহাসটি বাস্তবায়ন করি না ।

আমি এটি বাস্তবায়ন করেছি এবং এটি আমার প্রত্যাশার চেয়ে কম কষ্টকর। আমি যা করেছি তা এখানে:

  • আমি changelogsএকটি অটো-ইনক্রিমেন্ট আইডি কলাম সহ একটি একক টেবিল তৈরি করেছি
  • আমার সত্তাগুলির একটি idক্ষেত্র রয়েছে তবে এটি প্রাথমিক কী নয়
  • সত্তাগুলির একটি changeIdক্ষেত্র রয়েছে যা প্রাথমিক কী পাশাপাশি চ্যানেল লগগুলির একটি বিদেশী কী।
  • যখনই কোনও ব্যবহারকারী কোনও রেকর্ড তৈরি করে, আপডেট করে বা মুছে ফেলে, সিস্টেমটি একটি নতুন রেকর্ড সন্নিবেশ করে changelogs, আইডিটি ধরে এবং সত্তার একটি নতুন সংস্করণে নির্ধারণ করে , যা এটি পরে ডিবিতে সন্নিবেশ করে
  • আমার প্রশ্নগুলি সর্বোচ্চ রেকর্ডআইডি নির্বাচন করে (আইডি দ্বারা গোষ্ঠীযুক্ত) এবং সমস্ত রেকর্ডের সাম্প্রতিক সংস্করণগুলি পেতে স্ব-যোগদান করুন।
  • ফিল্টারগুলি সর্বশেষতম রেকর্ডগুলিতে প্রয়োগ করা হয় applied
  • একটি রাষ্ট্র ক্ষেত্র কোনও আইটেম মুছে ফেলা হয়েছে কিনা তা নজর রাখে
  • সর্বাধিক চেঞ্জআইডি ক্লায়েন্টকে ফিরিয়ে দেওয়া হয় এবং পরবর্তী অনুরোধগুলিতে ক্যোয়ারী প্যারামিটার হিসাবে যুক্ত করা হয়
  • যেহেতু শুধুমাত্র নতুন পরিবর্তন তৈরি করা হয়েছে, changeIdতত পরিবর্তন প্রতিটি মুহূর্তে পরিবর্তনটি তৈরির মুহুর্তে অন্তর্নিহিত ডেটার একটি অনন্য স্ন্যাপশট উপস্থাপন করে ।
  • এর অর্থ হল যে আপনি অনুরোধগুলির ফলাফলগুলিতে changeIdচিরতরে প্যারামিটার রেখেছেন। ফলাফলগুলি কখনই শেষ হবে না কারণ তারা কখনই পরিবর্তন করবে না।
  • এটি রোলব্যাক / রিভার্ট, ক্লায়েন্ট ক্যাশে সিঙ্ক করা ইত্যাদির মতো আকর্ষণীয় বৈশিষ্ট্যও খুলবে change এমন কোনও বৈশিষ্ট্য যা পরিবর্তনের ইতিহাস থেকে উপকৃত হয়।
— স্টিজন ডি উইট
সূত্র
আমি বিভ্রান্ত আপনি উল্লিখিত ব্যবহারের ক্ষেত্রে এটি কীভাবে সমাধান হবে? (ক্যাশে একটি এলোমেলো ক্ষেত্র পরিবর্তন হয় এবং আপনি ক্যাশেটি বাতিল করতে চান)
— ইউ আভালোস
আপনি নিজেকে যে কোনও পরিবর্তন করতে, আপনি কেবল প্রতিক্রিয়া তাকান। সার্ভারটি একটি নতুন পরিবর্তন সরবরাহ করবে এবং আপনি এটি আপনার পরবর্তী অনুরোধে ব্যবহার করবেন। অন্যান্য পরিবর্তনগুলির জন্য (অন্যান্য ব্যক্তিরা তৈরি করেছেন) আপনি সর্বশেষ পরিবর্তনটি একবারে একবারে পোল করুন এবং এটি যদি আপনার নিজের থেকে উচ্চতর হয় তবে আপনি জানেন যে অসামান্য পরিবর্তন রয়েছে। বা আপনি কিছু বিজ্ঞপ্তি সিস্টেম (দীর্ঘ পোলিং। সার্ভার পুশ, ওয়েবসকেট) সেট আপ করেছেন যা ক্লায়েন্টকে সতর্ক করে দেয় যখন সেখানে অসামান্য পরিবর্তন হয়।
— স্টিজন ডি উইট
0

আরইএসটিএফুল এপিআইগুলিতে প্যাজিনেশনের জন্য আরেকটি বিকল্প হ'ল এখানে প্রবর্তিত লিংক শিরোনামটি ব্যবহার করা । উদাহরণস্বরূপ গিথুব এটি অনুসরণ হিসাবে ব্যবহার করুন:

Link: <https://api.github.com/user/repos?page=3&per_page=100>; rel="next",
  <https://api.github.com/user/repos?page=50&per_page=100>; rel="last"

এর জন্য সম্ভাব্য মানগুলি হ'ল rel: প্রথম, শেষ, পরবর্তী, পূর্ববর্তী । তবে Linkশিরোনাম ব্যবহার করে , টোটাল_কাউন্ট (উপাদানগুলির মোট সংখ্যা) নির্দিষ্ট করা সম্ভব নয় ।

— adnanmuttaleb
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.