رسالة طلب النموذج: هل رقم الحقل هو اسمه؟

الخلاصة السريعة

راجع الرقم والنوع ومعنى الحقل وصيغة الإرسال معًا؛ لا تخلط إعادة تسمية خاصية بنقلها إلى رقم آخر أو بتبديل معناها.

• الرسالة الثنائية تستخدم رقم الحقل، ويقرأ الاسم والنوع بالرجوع إلى التعريف؛ الاسم وحده لا يكشف ما في البايتات. ^[1]
• في تعريفنا يحمل الرقم 1 كمية بوحدة معلنة؛ إعادة تسميتها مع ثبات الرقم والنوع والمعنى لا تنقلها إلى الحقل 2 في هذا المثال.
• تغيير رقم الحقل يحذف هويته السابقة وينشئ أخرى، ولا تعاد أرقام مستعملة؛ عند حذف حقل احجز رقمه واسمه وفق الإرشادات. ^[2]
• ProtoJSON يضع أسماء في الرسالة وله شروط مختلفة لتطور التعريف؛ راجع صيغة الإرسال، ولا تستنتج توافقه من مثالنا الثنائي. ^[3]

كيف يعرف القارئ الحقل الثنائي؟

توضح وثائق الترميز أن مفتاح الرسالة الثنائية رقم الحقل؛ أما الاسم والنوع المعلن فيقرآن بالرجوع إلى تعريف الرسالة. ^[1]

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

لو نظرنا إلى اسم المتغير في برنامج واحد دون تعريف الرسالة المقابل، لم نحدد ما يعنيه رقم بعينه عند الطرف الآخر. يحتاج التدقيق إلى اتفاق الطرفين على المعنى الذي نسبناه إلى تلك الهوية، لا إلى كلمة جميلة في التقرير.

إعادة تسمية لا تساوي تبديل هوية

نكتب في نسخة من تعريفنا اسم input_count للحقل 1، ثم نسميه item_count في تعريف بديل. نفترض ثبات الرقم ونوع العدد الصحيح ومعنى وحدة العمل. في هذا المثال يظل الرقم الذي يحدد الحقل هو 1؛ لم ننقله إلى 2.

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

هذه مقارنة لتعريفين نؤلفهما، وليست تجربة توافق مولدات شيفرة أو مكتبات. قد تعتمد شيفرة المستخدم على الاسم الذي يظهر لها. نراجع هذا المستوى مستقلًا بدل إخفاء أثره وراء حكم محدود عن هوية الإرسال الثنائي.

لماذا لا نعيد رقمًا قديمًا لمعنى جديد؟

تغيير رقم حقل يعد حذفًا وإضافة لهوية جديدة؛ تحذر الإرشادات من إعادة استخدام الأرقام، وتطلب حجز رقم واسم الحقل المحذوف. ^[2]

نفترض أن طلبنا القديم استخدم الرقم 2 لملاحظة نصية ثم حذفناها. لا نخصص 2 في البطاقة الجديدة لخاصية نصية أخرى بحجة أن نوعهما نص. تشابه النوع لا يعلن تطابق المعنى في السجلات السابقة.

نقترح حفظ الرقم المحجوز في تعريف الترحيل، وإسناد رقم جديد معلن لأي خاصية جديدة. ولا نعد وجود أسماء مختلفة علاجًا لسجل قديم فسر وفق تعريف آخر. المراجعة تحتاج معرفة ما صدر من كل تعريف وما يتوقعه القارئ.

ماذا يتغير إذا كانت الرسالة JSON؟

تضع ProtoJSON أسماء الحقول داخل الرسائل؛ ضمانات تطور التعريف تختلف عن الترميز الثنائي، ويكون تغيير الأسماء أصعب. ^[3]

لذلك نسأل عن صيغة النقل قبل قبول خطة التسمية. تحليلنا لهوية الرقم 1 لا يكفي لإعلان أن جميع مستهلكي اسم JSON سابق سيقبلون اسمًا جديدًا. نفصل مرجع التعريف الثنائي عن قواعد تمثيله النصي وعن عقد المعنى.

بطاقة المراجعة المقترحة تضم الرقم والاسم والنوع والوحدة والصيغة وتعريف الطرفين. لم نرمز رسالة أو نستدع خدمة نموذج. الرسم يحفظ الفرق بين اسمين للهوية المفترضة نفسها، ثم يضع مراجعة JSON مستقلة حتى لا يصبح حد الترميز ضمانًا عامًا.