كل نظام متصل له حدود، وهي الأماكن التي تعبر فيها البيانات من مكون إلى آخر. وفي هذه المواضع بالذات تتغير قواعد التحقق، لأن المستخدم يتوقع ردا فوريا في الطرف الأول، ولأن الطرف الثاني لا يثق في أي شيء لم يصدر منه. والتحقق عند حدود API ليس قاعدة إضافية فحسب، بل هو الإجابة على سؤال: من يحمي من؟
وهذا السؤال يظن كثيرون أنهم أجابوا عنه، ثم تنكشف الحقيقة في أول حادثة إنتاج عندما يظهر أن الفحصين لم يكونا نسختين من شيء واحد. فهم سطور متشابهة ومعان مختلفة، ووظيفة هذه المقالة أن تفصل بينهما.
ما معنى الحدود في تصميم واجهات API؟
الحد هو الموضع الذي تدخل فيه البيانات من خارج نظامك، أو تخرج منه. وحين تمر رزمة البيانات عبر هذا الموضع، فهي لم تعد تحت سيطرتك، لأن الكاتب ليس جزءا من مشروعك ولا يعمل تحت قواعدك. ولهذا تبدأ المواصفة من هذه النقطة، لا من فكرة أن الفريقين يتبادلان شيئا معروفا سلفا.
ولهذا السبب يكون الحد حادا مع كل شيء: لا نية مشتركة مسبقا، ولا ثقة متبادلة، ولا نسخة واحدة من الحقيقة. والفاحص الذي تدور على الشكل إجراءا واحدا يخالف هذا الواقع.
والمفهوم نفسه دقيق في كل نوع من الحدود. فالملف المستورد من نظام قديم، والنموذج الذي يصل من صفحة على شبكة عامة، والواجهة التي تستدعيها أداة خارجية—كل هذه المواضع استقبلت شيئا من خارج نظامك، ويجب أن تعامل بذلك الأساس.
ماذا يتحقق منه العميل؟
وظيفة العميل هي أن يمنع الخطأ ومن ثمة يقلل الوقت الضائع. فيتصدى للنقل والحالة والمسافات وحدود الطول. وفي شرط مثالي، لا يريد أن يفاجئ المستخدم بمكالمة بعيدة ردت رفضا بعد ثانيتين.
ولهذا ما يفعله العميل يفضل أن يكون سريعا. يستند إلى قواعد بسيطة يمكن تطبيقها في الزمن الحقيقي، ويعرض التوجيه أثناء الكتابة، ويشرح الفشل عند أول حقل مشكلة لا أن يلوم العدد.
وهذه الميزة تأتي بحدها. فعلى أي جهاز للمستخدم قد لا تصل النسخة التي فيها قواعد الخادم كاملة، وحين يتغير شيء في الخادم يبقى وقت طويل لا يعرف الفحص المحلي أن قاعدة تحولت. فالمنع ليس قيدا في صياغة التعارض بل انعكاس لكلفة الشبكة.
ماذا يجب أن يتحقق منه الخادم؟
الخادم هو النقطة التي تستطيع أن تقول إن شيئا لن يفسد البيانات. وهو عليه أن يفحص كما لو أن العميل لم يعمل أصلا: يتحقق من النوع المطلوب ومن اللفظ ومن الشكل ومن نطاق القيم، ومن كل قاعدة مرتبطة بأصل البيانات.
ولأن المدخل يمكن أن يأتي من أي مكان، فالفحص نفسه لا يمكن أن يفترض الصدق. العميل قد يكون قديما، أو معدلا من مستخدم تقني، أو غير موجود أصلا. وحقلا مثل طلب الحساب لا يمكن أن يكون فيه فحص آخر غير ما يجري في الخادم.
وتنشأ نقطة دقيقة في المعنى. الخادم يفحص ليسمح أو يمنع، ولا يسأل عن سبب المدخل. ولا يحاول أن يفهم نية العميل. ومعياره الواضح هو أن قاعدة كل قيمة قد كتبت مرة واحدة في موضع واحد هو مصدرها.
كيف تصف فشل التحقق في الاستجابة؟
الوصف جزء من الواجهة نفسها، لا مجرد رسالة. ولذلك يجب أن يبقى ثابتا: رمز حالة يمكن لأنظمة الأتمتة أن تستنتجه، وحقل نصي يبين ما يجري في الشكل، وبيانات تفصيلية تسمي الحقول المرفوضة.
والرمز القياسي لمدخل مشوه في طلب غير صالح هو HTTP 400. وزادت بعض المواصفات الحديثة رطبا خاصا هو HTTP 422 ليقول إن الطلب سليم البنية وإنما القيم لم تقبل القاعدة. والاثنان مقبولان ما دام الفريق ثابتا على أحدهما، لأن اختلاف الرمز يختبر سلوكيات العملاء أكثر مما يوصف الحالة.
وما يجعل الرسالة مفيدة هو التصنيف. فيجب أن تظهر أن الخطأ وقع في الشكل أو في الطول أو في خانة التحقق، وأن تميز بين رفض النظام المعروف وغياب النظام نفسه. ومن دون التفريق يكون الفريق قد كتب رمزا متسقا لكنه لا يوجه أحدا إلى مصدر الخطأ.
والقاعدة الأمنية أن تحرس القيمة كأنها معطى حساس، فالحالة التي تجعل الشاشة تفصح عن كل الأخطاء ولا تصف الأخطاء بها هي أسوأ من أن لا تقول شيئا.
لماذا لا يكفي التحقق في الواجهة؟
لأن الشيء الذي يستطيع تغييره يمكن تجاوزه، وهذا هو أصل قوة الواجهات وأصل خطرها في الوقت ذاته. فالمستخدم الذي يكتب مدخلات غير سليمة قد يجاوز الواجهة ببريد أو بأداة، وهذا حق لا يمكن منعه ولا ينبغي أن يحسب.
وقد تكون واجهات أخرى تعمل على النموذج الذي جرت كتابته سنوات قبل هذا الحد. فلو كانت المقدمة وحدها تعرف القاعدة كما هي اليوم، فالشفرة قديمة في نظام آخر لم يسمع بها. وهذه أحد الأسباب التي توجب أن يكون الكود دائما في الخادم.
وهذا هو المنطق نفسه الذي ظهر في بنية IBAN، لأن الأرقام في حساب طويل تحتاج معالجة دقيقة، ومحاولة تنفيذها في الواجهة بالطريقة السريعة تنتج نصوصا تخدع أكثر مما تخدع في حقل واحد.
الأداء والتخزين المؤقت
الحساب عند هذه الحدود يضيف إلى كلفة التشغيل. وحين يكون الحد تحت ضغط عال، فالفرق بين فحص خفيف وفحص ثقيل يصير محسوسا.
- لا تقس على عملية معقدة في كل طلب. أبسط متطلبات القاعدة يجري في الرأس.
- الأصول البعيدة أو السجلات الخارجية ليست الحد الأول. فتلك توفرها مرحلة منفصلة كما شرح في سير عمل التحقق بدفعات.
- لا تخزن نتيجة الفحص في مكان مشترك قبل التحقق من كل التبعات، ولا سيما إذا كانت تستند إلى قواعد تتغير.
- اجعل الفشل واضحا منذ السطور الأولى حتى لا يكون فرق السلوك بين البيئات هو الباب الذي يستحق أن يدفع ثمنه.
والأثر الجانبي لبعض الحدود قد يتغير مع الوقت. فالتخزين المؤقت الحاد مع قواعد صارمة قد ينتج واجهة تقبل قيمة واحدة ثم ترفضها بعد. والأفضل هو أن يعاد الفحص عند حدود الكتابة دائما، ولا يجري تعيينه بمخرجات فحص قديمة.
الخطوات التالية
حدد قواعد الفحص التي تعيش في كل طرف، واكتب في الجدول ما إذا كانت للسرعة أم للحمى. ثم لاحظ أي قاعدة مكتوبة في الطرفين بصورة مختلفة، وأعدها إلى مصدر واحد. وأخيرا اقرأ كيف يعمل التحقق من الأرقام لترجمة الخطوات الأربع إلى مراحل الفحص هذه، وستبين لك أداة التحقق من الأرقام الفرق في الرسائل وفي التطبيق الصحيح.