การแบ่งหน้าในเว็บแอ็พพลิเคชัน REST

นี่คือการปฎิรูปทั่วไปของคำถามนี้ (ด้วยการกำจัดส่วนเฉพาะของ Rails)

ฉันไม่แน่ใจว่าจะใช้การแบ่งหน้าในแหล่งข้อมูลในเว็บแอปพลิเคชัน RESTful ได้อย่างไร สมมติว่าฉันมีทรัพยากรที่เรียกว่าproductsสิ่งใดต่อไปนี้ที่คุณคิดว่าเป็นแนวทางที่ดีที่สุดและทำไม:

1. ใช้สตริงข้อความค้นหาเท่านั้น

เช่น. http://application/products?page=2&sort_by=date&sort_how=asc
ปัญหาที่นี่คือฉันไม่สามารถใช้การแคชแบบเต็มหน้าและ URL ไม่สะอาดและง่ายต่อการจดจำ

2. การใช้หน้าเป็นทรัพยากรและสตริงแบบสอบถามสำหรับการเรียงลำดับ

เช่น. http://application/products/page/2?sort_by=date&sort_how=asc
ในกรณีนี้ปัญหาที่เห็นคือhttp://application/products/pages/1ไม่ได้เป็นทรัพยากรที่ไม่ซ้ำกันเนื่องจากการใช้sort_by=priceสามารถให้ผลลัพธ์ที่แตกต่างกันโดยสิ้นเชิงและฉันยังไม่สามารถใช้การแคชหน้า

3. การใช้หน้าเป็นทรัพยากรและส่วน URL สำหรับการเรียงลำดับ

เช่น. http://application/products/by-date/page/2
ฉันเองเห็นว่าไม่มีปัญหาในการใช้วิธีนี้ แต่มีคนเตือนฉันว่านี่ไม่ใช่วิธีที่ดีที่จะไป (เขาไม่ได้ให้เหตุผลดังนั้นถ้าคุณรู้ว่าทำไมมันถึงไม่แนะนำกรุณาแจ้งให้เราทราบ)

ใด ๆข้อเสนอแนะความคิดเห็นวิพากษ์วิจารณ์มากกว่าการต้อนรับ ขอบคุณ

ฉันคิดว่าปัญหาของเวอร์ชัน 3 เป็นปัญหา "มุมมอง" มากกว่านี้ - คุณเห็นหน้าเว็บเป็นทรัพยากรหรือผลิตภัณฑ์ในหน้า

หากคุณเห็นว่าหน้าเป็นทรัพยากรมันเป็นทางออกที่ดีอย่างสมบูรณ์เนื่องจากแบบสอบถามสำหรับหน้า 2 จะให้ผลหน้า 2 เสมอ

แต่ถ้าคุณเห็นผลิตภัณฑ์ในหน้าเป็นทรัพยากรคุณมีปัญหาว่าผลิตภัณฑ์ในหน้า 2 อาจเปลี่ยนแปลง (ลบผลิตภัณฑ์เก่าหรืออะไรก็ตาม) ในกรณีนี้ URI จะไม่ส่งคืนทรัพยากรเดียวกันเสมอ

เช่นลูกค้าจัดเก็บลิงค์ไปยังหน้ารายการผลิตภัณฑ์ X ในครั้งถัดไปที่เปิดลิงค์ผลิตภัณฑ์ที่สงสัยอาจจะไม่อยู่ในหน้า X อีกต่อไป

ฉันเห็นด้วยกับ Fionn แต่ฉันจะไปอีกขั้นหนึ่งแล้วบอกฉันว่าเพจไม่ใช่ทรัพยากร แต่เป็นคุณสมบัติของคำขอ นั่นทำให้ฉันเลือกสตริงแบบสอบถาม 1 ตัวเลือกเท่านั้น มันรู้สึกถูกต้อง ฉันชอบวิธีการที่Twitter APIมีโครงสร้างอย่างสงบ ไม่ง่ายเกินไปไม่ซับซ้อนเกินไปจัดทำเป็นเอกสารอย่างดี ไม่ว่าจะดีหรือแย่กว่านั้นมันคือการออกแบบ "ไปที่" ของฉันเมื่อฉันอยู่บนรั้วเพื่อทำบางสิ่งทางเดียวกับอีกวิธีหนึ่ง

HTTP มีส่วนหัว Range ที่ยอดเยี่ยมซึ่งเหมาะสำหรับการแบ่งหน้าด้วย คุณสามารถส่ง

Range: pages=1

มีหน้าแรกเท่านั้น ที่อาจบังคับให้คุณคิดใหม่หน้าคืออะไร บางทีลูกค้าต้องการรายการที่แตกต่างกัน ส่วนหัวของช่วงยังทำงานเพื่อประกาศคำสั่งซื้อ:

Range: products-by-date=2009_03_27-

เพื่อรับผลิตภัณฑ์ใหม่ทั้งหมดกว่าวันที่หรือ

Range: products-by-date=0-2009_11_30

เพื่อรับผลิตภัณฑ์ทั้งหมดที่เก่ากว่าวันที่นั้น '0' อาจไม่ใช่วิธีที่ดีที่สุด แต่ RFC ดูเหมือนจะต้องการบางสิ่งบางอย่างสำหรับช่วงเริ่มต้น อาจมีการใช้ตัวแยกวิเคราะห์ HTTP ซึ่งจะไม่แยกวิเคราะห์หน่วย = -range_end

หากส่วนหัวไม่ใช่ตัวเลือก (ยอมรับได้) ฉันคิดวิธีแก้ปัญหาแรก (ทั้งหมดในสตริงข้อความค้นหา) เป็นวิธีจัดการกับหน้าเว็บ แต่โปรดทำให้คำสั่งสตริงการค้นหา (เรียงลำดับ (คีย์ = ค่า) เป็นปกติตามลำดับตัวอักษร) วิธีนี้จะช่วยแก้ปัญหาความแตกต่างของ "? a = 1 & b = x" และ "? b = x & a = 1"

ตัวเลือกที่ 1 นั้นดูดีที่สุดเท่าที่แอปพลิเคชันของคุณมองว่าการแบ่งหน้าเป็นเทคนิคในการสร้างมุมมองที่แตกต่างกันของทรัพยากรเดียวกัน

ต้องบอกว่ารูปแบบ URL ค่อนข้างไม่มีนัยสำคัญ หากคุณกำลังออกแบบแอปพลิเคชันของคุณให้เป็นไฮเปอร์เท็กซ์ขับเคลื่อน (เนื่องจากแอปพลิเคชัน REST ทั้งหมดต้องเป็นไปตามคำจำกัดความ) ไคลเอ็นต์ของคุณจะไม่สร้าง URIs ใด ๆ ด้วยตัวเอง แอปพลิเคชันของคุณจะให้ลิงก์ไปยังลูกค้าแทนและลูกค้าจะติดตามพวกเขา

ลิงค์ประเภทหนึ่งที่ลูกค้าของคุณสามารถให้ได้คือลิงค์สำหรับการแบ่งหน้า

ผลข้างเคียงที่น่าพอใจของทั้งหมดนี้คือแม้ว่าคุณจะเปลี่ยนใจเกี่ยวกับโครงสร้างการแบ่งหน้า URI และใช้สิ่งที่แตกต่างกันโดยสิ้นเชิงในสัปดาห์หน้าลูกค้าของคุณสามารถทำงานต่อไปได้โดยไม่ต้องแก้ไขอะไรเลย

ฉันมักจะใช้รูปแบบของตัวเลือกที่ 1 เสมอแคชไม่ได้เป็นเรื่องที่กังวลเนื่องจากข้อมูลมีการเปลี่ยนแปลงบ่อยในกรณีของฉัน หากคุณอนุญาตให้ปรับขนาดหน้าได้อีกครั้งข้อมูลจะไม่ถูกแคช

ฉันไม่พบ URL ที่จำยากหรือสกปรก สำหรับฉันนี่คือการใช้พารามิเตอร์การสืบค้นที่ดี ทรัพยากรเป็นรายการผลิตภัณฑ์อย่างชัดเจนและพารามิเตอร์การสืบค้นกำลังบอกวิธีที่คุณต้องการแสดงรายการ - เรียงลำดับและหน้าใด

แปลกที่ไม่มีใครชี้ให้เห็นว่าตัวเลือก 3 มีพารามิเตอร์ตามลำดับเฉพาะ http // แอปพลิเคชัน / ผลิตภัณฑ์ / วันที่ / มากไปน้อย / ชื่อ / จากน้อยไปมาก / หน้า / 2 และ http // แอปพลิเคชัน / ผลิตภัณฑ์ / ชื่อ / จากน้อยไปมาก / วันที่ / มากไปน้อย / หน้า / 2

กำลังชี้ไปที่ทรัพยากรเดียวกัน แต่มี URL ที่แตกต่างอย่างสิ้นเชิง

สำหรับฉันตัวเลือกที่ 1 ดูเหมือนจะเป็นที่ยอมรับมากที่สุดเพราะมันแยก"สิ่งที่ฉันต้องการ"และ"ฉันต้องการ"ได้อย่างชัดเจน (มันยังมีเครื่องหมายคำถามระหว่างพวกเขา lol) การแคชแบบเต็มหน้าสามารถดำเนินการได้โดยใช้ URL แบบเต็ม (ตัวเลือกทั้งหมดจะประสบปัญหาเดียวกันอยู่แล้ว)

ด้วยวิธีการพารามิเตอร์ใน URL ประโยชน์เพียงอย่างเดียวคือ URL ที่สะอาด แม้ว่าคุณจะต้องมีวิธีการเข้ารหัสพารามิเตอร์และถอดรหัสพวกเขาโดยไม่สูญเสียไป แน่นอนคุณสามารถไปกับ URL รหัส / ถอดรหัส แต่มันจะทำให้ URL น่าเกลียดอีกครั้ง :)

ฉันต้องการใช้การชดเชยและ จำกัด พารามิเตอร์การสืบค้น

ชดเชย : สำหรับดัชนีของรายการในคอลเลกชัน

ข้อ จำกัด : สำหรับจำนวนรายการ

ลูกค้าสามารถอัปเดตออฟเซ็ตได้ดังต่อไปนี้

offset = offset + limit

สำหรับหน้าถัดไป

เส้นทางนั้นถือเป็นตัวระบุทรัพยากร และหน้าไม่ใช่ทรัพยากร แต่เป็นส่วนย่อยของการรวบรวมทรัพยากร เนื่องจากการแบ่งหน้าโดยทั่วไปเป็นคำขอ GET พารามิเตอร์การค้นหาจึงเหมาะที่สุดสำหรับการแบ่งหน้ามากกว่าส่วนหัว

การอ้างอิง: https://metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page

กำลังมองหาแนวทางปฏิบัติที่ดีที่สุดที่ฉันพบในไซต์นี้:

http://www.restapitutorial.com

ในหน้าทรัพยากรมีลิงค์สำหรับดาวน์โหลดไฟล์. pdf ที่มีวิธีปฏิบัติที่ดีที่สุดสำหรับ REST ที่ผู้เขียนแนะนำ นอกจากนี้ยังมีหัวข้อเกี่ยวกับการให้เลขหน้า

ผู้เขียนขอแนะนำให้เพิ่มการสนับสนุนให้กับทั้งการใช้ส่วนหัวของช่วงและการใช้พารามิเตอร์แบบสอบถามสตริง

ขอร้อง

ตัวอย่างส่วนหัว HTTP:

Range: items=0-24

ตัวอย่างพารามิเตอร์เคียวรีสตริง:

GET http://api.example.com/resources?offset=0&limit=25

โดยที่offsetเป็นหมายเลขรายการเริ่มต้นและข้อ จำกัดคือจำนวนรายการสูงสุดที่จะส่งคืน

คำตอบ

การตอบสนองควรมีส่วนหัวช่วงเนื้อหาที่ระบุจำนวนรายการที่จะถูกส่งคืนและจำนวนรายการทั้งหมดที่ยังไม่ถูกเรียกคืน

ตัวอย่างส่วนหัว HTTP:

Content-Range: items 0-24/66

Content-Range: items 40-65/*

ใน. pdf มีคำแนะนำอื่น ๆ สำหรับกรณีที่เฉพาะเจาะจงมากขึ้น

ขณะนี้ฉันใช้รูปแบบคล้ายกับสิ่งนี้ในแอป ASP.NET MVC ของฉัน:

เช่น http://application/products/by-date/page/2

โดยเฉพาะมัน: http://application/products/Date/Ascending/3

อย่างไรก็ตามฉันไม่พอใจกับการรวมเพจและข้อมูลการเรียงลำดับในเส้นทางด้วยวิธีนี้

รายการของรายการ (ผลิตภัณฑ์ในกรณีนี้) ไม่แน่นอน เช่นครั้งต่อไปที่มีคนกลับไปที่ URL ที่มีพารามิเตอร์การเพจและการเรียงลำดับผลลัพธ์ที่พวกเขาได้รับอาจมีการเปลี่ยนแปลง ดังนั้นแนวคิดhttp://application/products/Date/Ascending/3ในการเป็น URL เฉพาะที่ชี้ไปที่ชุดผลิตภัณฑ์ที่ไม่เปลี่ยนแปลงจึงหายไป

ฉันมักจะเห็นด้วยกับ slf ว่า "หน้า" ไม่ได้เป็นทรัพยากรจริงๆ ในทางตรงกันข้ามตัวเลือกที่ 3 นั้นสะอาดกว่าอ่านง่ายขึ้นและสามารถเดาได้ง่ายโดยผู้ใช้และพิมพ์ออกมาหากจำเป็น ฉันขาดระหว่างตัวเลือก 1 และ 3 แต่ไม่เห็นเหตุผลที่จะไม่ใช้ตัวเลือก 3

ในขณะที่พวกเขาดูดีข้อเสียข้อหนึ่งของการใช้พารามิเตอร์ที่ซ่อนอยู่ดังที่มีคนพูดถึงแทนที่จะเป็นสตริงข้อความค้นหาหรือเซ็กเมนต์ URL คือผู้ใช้ไม่สามารถคั่นหน้าหรือเชื่อมโยงไปยังหน้าใดหน้าหนึ่งโดยตรง อาจเป็นหรือไม่เป็นปัญหาขึ้นอยู่กับแอปพลิเคชัน แต่เป็นเพียงสิ่งที่ต้องระวัง

ฉันเคยใช้โซลูชัน 3 มาก่อน (ฉันเขียนแอพ django มากมาย) และฉันไม่คิดว่ามีอะไรผิดปกติกับมัน มันสามารถสร้างได้เหมือนอย่างที่สอง (ในกรณีที่คุณต้องทำการขูดมวลหรือสิ่งที่คล้ายกัน) และดูสะอาดกว่า นอกจากนี้ผู้ใช้ของคุณสามารถคาดเดา URL (ถ้าเป็นแอพที่ต้องพบเจอกับสาธารณะ) และผู้คนสามารถไปที่ที่พวกเขาต้องการได้โดยตรง

ฉันใช้ในโครงการของฉันตาม URL ต่อไปนี้:

http://application/products?page=2&sort=+field1-field2

ซึ่งหมายความว่า - "ให้ฉันหน้าหน้าที่สองสั่งจากน้อยไปมากโดย field1 และจากนั้นมากไปน้อยโดย field2" หรือถ้าฉันต้องการความยืดหยุ่นที่มากขึ้นฉันใช้:

http://application/products?skip=20&limit=20&sort=+field1-field2

ฉันใช้ในรูปแบบต่อไปนี้เพื่อรับการบันทึกหน้าถัดไป http: // แอพลิเคชัน / ผลิตภัณฑ์ lastRecordKey = & pagesize = 20 & sort = ASC

RecordKey เป็นคอลัมน์ของตารางที่เก็บค่าลำดับใน DB ใช้เพื่อดึงข้อมูลหน้าเดียวในแต่ละครั้งจากฐานข้อมูล pageSize ใช้เพื่อกำหนดจำนวนระเบียนที่จะดึงข้อมูล sort ใช้เพื่อเรียงลำดับเร็กคอร์ดในลำดับขึ้นหรือลง