تقليل نقل بيانات API مفيد، لكن الاستجابة 304 ليست هدفًا مستقلًا. يجب أن تعني أن نسخة المستخدم الحالية ما زالت صالحة، وأنه يملك حق الوصول إليها. عند إضافة ETag اختبر تغير المورد وعزل الحسابات، ولا تجعل نجاح إعادة استخدام الكاش يخفي بيانات قديمة أو مشاركة غير مقصودة.
حدد النسخة التي يمثلها الوسم
توضح وثائق MDN لترويسة ETag استخدامها للتحقق من نسخة المورد. في طلب GET يحمل If-None-Match، يمكن أن يعيد الخادم 304 إذا بقيت النسخة مطابقة، دون إرسال جسم المورد من جديد. هذا لا يحل تلقائيًا تحديد صلاحيات المستخدم أو سياسة تخزين الرد.
اكتب ما يؤثر في التمثيل: اللغة، الحقول المختارة، دور المستخدم، أو حالة الطلب. إذا تغيرت بيانات ظاهرة ولم يتغير الوسم المناسب، قد يبقى العميل على نسخة قديمة. وإذا عاملت تمثيلين مختلفين كأنهما متطابقان، يصبح الاختبار ناجحًا ظاهريًا رغم اختلاف ما ينبغي عرضه.
اختبر المسار الأساسي وتغير البيانات
| الطلب التجريبي | النتيجة المطلوبة وفق التصميم |
|---|---|
| أول GET للمورد | تمثيل صحيح مع بيانات التحقق المناسبة |
| GET بشرط مطابق دون تعديل | 304 عندما تسمح سياسة المورد بذلك |
| تعديل حقل ظاهر ثم إعادة التحقق | نسخة جديدة ووسم يعكس التغير |
| سحب الصلاحية ثم تكرار الطلب | تطبيق قرار الوصول الحالي قبل إعادة الاستخدام |
نفذ الحالات بعميل اختبار يسجل الترويسات وحالة الرد وحجم الجسم، ثم قارن الواجهة بعد إعادة التحقق. لا تقرأ رقم الحالة وحده؛ راجع أن العميل يحتفظ بالنسخة الصحيحة ويتعامل مع تعديل المورد أو انتهاء الجلسة برسالة مناسبة.
افصل التحقق من مشاركة الكاش
تشرح وثائق MDN للكاش الفرق بين المخزن الخاص والمشترك، وأن وجود Cookie لا يجعل الرد خاصًا تلقائيًا. اختر ترويسات تناسب حساسية البيانات وبنية التطبيق؛ private يحدد نطاق التخزين الخاص، بينما no-store يمنع التخزين ولا يمحو بالضرورة نسخة محفوظة سابقًا.
في سيناريو افتراضي، لحسابين رابط API بالشكل نفسه لكنه يعرض طلبات مختلفة. افتح المورد بحساب أ ثم ب عبر المسار الكامل، بما فيه الوكيل أو CDN إن وجد في بيئة الاختبار. تأكد من عدم انتقال جسم أ إلى ب، ومن أن النظام لا يعتمد على اختلاف ETag وحده لحماية الصلاحيات.
وثق عقد العميل والخادم
حدد متى يسمح للعميل باستخدام نسخة سابقة، وكيف يعيد التحقق بعد تعديل محلي، وما السلوك عند فشل الاتصال. راجع مفاتيح الكاش داخل التطبيق وأي Service Worker، لأن طبقة مخصصة قد تتبع قواعد مختلفة عن كاش المتصفح المعتاد. لا تختبر نقطة الخادم وحدها ثم تعمم النتيجة على كل الطبقات.
ضمن تطوير أنظمة المؤسسات اربط سياسة الكاش بنوع البيانات ومتطلبات العرض. ويمكن إجراء مراجعة تقنية لمصفوفة الحسابات والترويسات. الدليل المطلوب يجمع تقليل النقل وصحة المحتوى والتحكم في الوصول؛ انخفاض حجم الرد لا يكفي إذا بقيت واجهة المستخدم على معلومة غير صحيحة.
