استجابة وهمية مقسَّمة إلى صفحات

تعمل في المتصفح المحاكاة

اختر نمط التقسيم إلى صفحات وحجم الصفحة والعدد الإجمالي لتوليد استجابات الصفحة الأولى والوسطى والأخيرة، بما فيها الروابط والمؤشرات والإجماليات.

بيانات اختبار فقط — جميع الأسماء وبيانات الاتصال والمعرّفات والأرقام المولّدة اصطناعية ولا تعود لأشخاص أو حسابات حقيقية.
الخصوصية: تعمل هذه الأداة بالكامل في متصفحك. لا تغادر بياناتك جهازك أبداً.

ما هي محاكاة واجهات API؟

الواجهة الوهمية (mock) تعيد استجابات محددة مسبقاً بدلاً من الخدمة الحقيقية، بحيث يمكن بناء الواجهة الأمامية أو التكامل أو حزمة الاختبار وتجربتها قبل وجود الخلفية أو دون الاعتماد عليها. المحاكاة الجيدة تعيد إنتاج العقد الحقيقي — رموز الحالة والترويسات والترقيم وأجسام الأخطاء — وإلا نجحت الاختبارات مع المحاكاة وفشلت مع الإنتاج.

اقرأ الدليل: ما هو اختبار API؟ وكيف تختبر REST API

كيفية استخدام استجابة وهمية مقسَّمة إلى صفحات

  1. اختر النمط والعدد الإجمالي للعناصر وحجم الصفحة.
  2. اختر الصفحة الأولى/الوسطى/الأخيرة أو صفحة محدّدة.
  3. ولّد الاستجابات واستخدم كل صفحة لاختبار حالات القوائم والتمرير و«تحميل المزيد» (load more).

مزايا استجابة وهمية مقسَّمة إلى صفحات

  • أنماط التقسيم إلى صفحات: برقم الصفحة أو الإزاحة (offset) أو المؤشر (cursor) أو مجموعة المفاتيح (keyset) أو ترويسة Link
  • الصفحات الأولى والوسطى والأخيرة في تشغيل واحد، أو أي صفحة محدّدة
  • معرّفات عناصر متسلسلة عبر الصفحات ومؤشرات base64url قابلة لفك الترميز
  • الروابط وعلامتا hasNext/hasPrev والإجماليات وترويسة X-Total-Count
  • حقول عناصر واسم مورد مخصّصة؛ وقابل للتوليد ببذرة (seed)

مثال على استجابة وهمية مقسَّمة إلى صفحات

الصفحة الثانية من ثلاث

الإدخال:

Style: page, total: 25, page size: 10, page: 2

النتيجة:

{ "data": [ { "id": 11, … }, …, { "id": 20, … } ], "meta": { "page": 2, "pageSize": 10, "total": 25, "totalPages": 3, "hasPrev": true, "hasNext": true }, "links": { "prev": "…?page=1&pageSize=10", "next": "…?page=3&pageSize=10" } }
مع 25 عنصراً و10 عناصر في كل صفحة تضم الصفحة 2 المعرّفات ⁦11⁠–⁠20⁩ وفيها رابطا السابق والتالي؛ يطلبها نمطا رقم الصفحة والإزاحة مباشرةً، بينما يتبع نمطا مجموعة المفاتيح والمؤشر رابط التالي في الصفحة 1.

المثال: 25 عنصراً، حجم الصفحة 10، 3 صفحات

الصفحة

1 2 3

معرّفات العناصر

1–10 11–20 21–25 —

رابطا السابق/التالي

next prev + next prev

برقم الصفحة

page=1 page=2 page=3

الإزاحة (offset)

offset=0 offset=10 offset=20

مجموعة المفاتيح (keyset)

— after_id=10 after_id=20

المؤشر (cursor)

— cursor=… ({"id":10,…}) cursor=… ({"id":20,…})

الشرطة تحت الصفحة 1: الطلب الأول بلا after_id ولا cursor. ولا تحمل صفحات مجموعة المفاتيح إلا رابط next. ويرسل كل طلب أيضاً حجم الصفحة (pageSize أو limit أو per_page)؛ ويطلب نمط ترويسة Link الصفحة كما يطلبها نمط رقم الصفحة.

الأسئلة الشائعة حول استجابة وهمية مقسَّمة إلى صفحات

ما أنماط التقسيم إلى صفحات المدعومة؟

برقم الصفحة (page/pageSize/totalPages)، وoffset/limit، والمؤشر (pageInfo مع مؤشرات base64url مبهمة)، ومجموعة المفاتيح (after_id)، وترويسات Link على نمط GitHub.

لماذا الصفحات الأولى والوسطى والأخيرة؟

لأنها تختبر الحالات الثلاث التي يجب على العميل التعامل معها: غياب رابط السابق، ووجود الرابطين معاً، وصفحة أخيرة ممتلئة جزئياً بلا رابط للتالي. ولّد صفحة محدّدة عندما تحتاج إلى صفحة أخرى.

هل المؤشرات قابلة لفك الترميز؟

نعم. المؤشرات عبارة عن JSON مرمَّز بـ base64url مثل {"id":10,"dir":"next"}، حتى تتمكن من فحصها وصياغتها في الاختبارات.

كيف تُعيَّن معرّفات العناصر؟

بالتسلسل عبر الصفحات (تبدأ الصفحة 2 بحجم 10 من المعرّف 11)، حتى يمكن التحقق من منطق الترتيب وإزالة التكرار.

المراجع

  • OpenAPI SpecificationOpenAPI Initiativeالمعيار لوصف واجهات REST: المسارات والعمليات والمعاملات والمخططات والاستجابات وأنظمة الأمان.
  • RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
  • RFC 8288: Web LinkingIETF · 2017ترويسة Link وعلاقات الروابط (next وprev وfirst وlast) المستخدمة لترقيم صفحات API.