في الأساس، هذه ليست مشكلة توثيق، بل هي مشكلة تنفيذ.
طرح @avdi هذا منذ سنوات وهناك إجماع داخلي واسع على أن المسار الصحيح للمضي قدمًا هو واجهة برمجة تطبيقات JSON/REST مناسبة ومُصنفة مع معلمات وأشكال متسقة للبيانات.
حاليًا، واجهة برمجة التطبيقات التي نقدمها هي واجهة برمجة التطبيقات الداخلية الخاصة بنا. إنها مكتملة وشاملة بنسبة 100%، ولكنها غير مريحة ومتغيرة الشكل. الأشكال التي تعيدها ونقاط النهاية مُحسّنة بالكامل لتشغيل تطبيق Ember من جانب العميل. إنها تتطور وتتغير أشكالها مع مرور الأشهر، مما يجعل الاعتماد عليها في المهام الحيوية أمرًا صعبًا. البناء عليها أكثر تعقيدًا مما ينبغي.
ستحل مجموعة جديدة تمامًا من وحدات التحكم والطرق مشكلة الاستقرار هنا وتسمح لنا بإعادة الأشكال التي تبدو منطقية أكثر لواجهة برمجة تطبيقات REST. على سبيل المثال:
/api/v0/topic/1234.json يمكن أن تعيد شكلاً أكثر “اتساقًا مع ممارسات واجهة برمجة التطبيقات العامة”.
هناك الكثير من “اهتمامات عميل Ember فقط” المعقدة للغاية في ملف JSON الخاص بالموضوع:
timeline_lookup و post_stream و tags_descriptions إلخ… إلخ…
ومع ذلك، هذا مشروع ضخم للشروع فيه، سنحتاج إلى الكثير من إعادة التصميم الداخلي لضمان عدم تكرار المنطق. بالإضافة إلى ذلك، تجعل الإضافات هذا الأمر أكثر تعقيدًا لأنها تعيد تشكيل الكثير من السلوك الداخلي الذي سيحتاج إلى انعكاس في واجهة برمجة التطبيقات. (ماذا يفعل التعيين لهذه الأشكال؟)
أنا بالتأكيد أرى أننا سنشرع في هذه المغامرة ولكن ليس في المستقبل القريب.