هل برونو أسلوب الطلب أولاً؟ متى تحتاج أداة تصميم أولاً

هل برونو يعتمد على الطلبات أولاً؟ نعم. تم تصميم برونو حول إنشاء طلبات HTTP وتنظيمها وإرسالها. يمكنك إنشاء مجموعة، إضافة طلبات، كتابتها في ملفاته .bru، تشغيلها، وتوثيق كل ذلك في Git. هذا النموذج سريع، متوافق مع Git، وممتع حقًا عند استكشاف واجهة برمجة تطبيقات (API) موجودة بالفعل.

ولكن "الطلبات أولاً" و "التصميم أولاً" يجيبان على أسئلة مختلفة. يسأل نهج الطلبات أولاً: كيف أستدعي نقطة النهاية هذه؟ ويسأل نهج التصميم أولاً: كيف يجب أن تكون نقطة النهاية هذه، قبل أن يكتب أي شخص رمزًا لتقديمها؟ الفجوة بين هذين السؤالين هي بالضبط حيث تبدأ الفرق التي تبني واجهات برمجة تطبيقات (APIs) جديدة أو مشتركة في الشعور بالاحتكاك. تستعرض هذه المقالة المفاضلة بين نهج برونو للطلبات أولاً ونهج التصميم أولاً بصراحة، ثم توضح أين يكتسب سير عمل التصميم أولاً والقائم على OpenAPI مكانته.

الطلبات أولاً مقابل التصميم أولاً، باختصار

لا يعتبر النهجان متنافسين بقدر ما هما نقطتا بداية مختلفتان. إليك النسخة المختصرة.

ليس أي من العمودين "خاطئًا". يعتمد الاختيار الصحيح على ما إذا كانت واجهة برمجة التطبيقات (API) الخاصة بك موجودة بالفعل أم أنك تقوم بتعريفها الآن.

نموذج برونو للطلبات أولاً

يقوم برونو بعمله بشكل جيد، ومن الجدير بالذكر أن نكون دقيقين بشأن ماهية هذا العمل. يقوم بتخزين الطلبات كملفات نصية .bru في مجلد تملكه. لا يوجد حساب سحابي إلزامي، ولا مزامنة خاصة، ولا قياس عن بعد في الخلفية يجب عليك إلغاء الاشتراك فيه. بالنسبة للمطورين الذين يريدون أن يتصرف عميل واجهة برمجة التطبيقات (API) الخاص بهم مثل بقية قاعدة الكود الخاصة بهم، فهذه ميزة حقيقية، وهي جوهر سير عمل واجهة برمجة التطبيقات الأصيل لـ Git الذي اعتمدته العديد من الفرق.

حيث يتألق برونو:

• استكشاف واجهة برمجة تطبيقات (API) موجودة. وجهه إلى خدمة قيد التشغيل، أطلق الطلبات، افحص الاستجابات، كرر. حلقة التغذية الراجعة محكمة.
• محلي أولاً ومتوافق مع Git. الفروقات قابلة للقراءة، وعمليات الدمج منطقية، وتاريخ طلباتك يعيش في نفس طلب السحب (PR) مثل الكود الخاص بك.
• البرمجة النصية والاختبار. تغطي النصوص البرمجية قبل وبعد الطلب، والتأكيدات، والمتغيرات البيئية الاختبار اليومي الذي يحتاجه معظم المهندسين.
• لا يوجد تقييد. التنسيق مفتوح والملفات ملكك.

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

تكلفة عدم وجود طبقة تصميم أو عقد

تظهر المفاضلة لحظة عدم وجود واجهة برمجة التطبيقات (API) بعد، أو لحظة اضطرار أكثر من فريق واحد للاتفاق على الشكل الذي يجب أن تكون عليه.

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

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

مراجعة أصعب بين الفرق قبل الكود. مراجعة مجلد من الطلبات يخبرك بكيفية استدعاء نقاط النهاية اليوم. لا يمنح المراجع مستندًا واضحًا ومعلنًا للموافقة عليه قبل التنفيذ. بالنسبة للفرق التي تفرض تغييرات واجهة برمجة التطبيقات (API) من خلال مراجعة التصميم، فإن غياب عقد من الدرجة الأولى يجعل هذه المراجعة أبطأ وأكثر عشوائية.

لا شيء من هذا يجعل برونو أداة سيئة. إنه يجعل برونو أداة تعتمد على الطلبات أولاً، ولكنها تُستخدم خارج نطاق عملها الأساسي الذي صُممت له.

متى يفوز نهج التصميم أولاً

يؤتي نهج التصميم أولاً ثماره في ثلاث حالات على وجه الخصوص:

• واجهات برمجة تطبيقات جديدة تمامًا (Greenfield APIs). عندما لا يوجد شيء بعد، تكون المواصفات هي التصميم. تحدد الموارد والمخططات وأشكال الأخطاء مرة واحدة، ثم تنشئ نماذج الخادم، والمحاكاة، والتوثيق من ذلك العقد الفردي بدلاً من استنتاجها من الطلبات لاحقًا.
• عقود متعددة الفرق. عندما يجب أن يتفق فريق الواجهة الخلفية وفريق عميل واحد أو أكثر، تكون مواصفات OpenAPI هي الاتفاق. يمكن للواجهة الأمامية البناء مقابل نموذج بمجرد الموافقة على العقد، بالتوازي مع تنفيذ الواجهة الخلفية، بدلاً من انتظار نقاط النهاية الحقيقية.
• واجهات برمجة التطبيقات العامة. عندما يعتمد المطورون الخارجيون عليك، فإن الاستقرار والتوثيق الواضح هما المنتج. يمنحك العقد المحافظ عليه وثائق مرجعية مُنشأة، وانضباطًا في الإصدارات، وطريقة لتوصيل التغييرات الجذرية عمدًا.

الخيط المشترك: يفوز نهج التصميم أولاً عندما تكون واجهة برمجة التطبيقات (API) واجهة مشتركة تحتاج إلى اتفاق قبل الكود، وليس مجرد خدمة تستكشفها بعد إطلاقها.

Apidog تصميم أولاً بالإضافة إلى وضع المواصفات أولاً

تم تصميم Apidog بنهج التصميم أولاً، والنقطة المهمة هنا هي أنك لا تضطر للتخلي عن تجربة OpenAPI الأصيلة والمتوافقة مع Git للحصول عليه.

يمكنك العمل بطريقتين على نفس المشروع. مصمم مرئي لتحديد نقاط النهاية، ومخططات الطلبات والاستجابات، والمكونات القابلة لإعادة الاستخدام دون كتابة YAML يدويًا، وهو ما يتخيله معظم الناس عندما يسمعون "التصميم أولاً". وهناك وضع "المواصفات أولاً" (Spec-First Mode)، وهو محرر كود حيث تقوم بتأليف مستند OpenAPI مباشرة، مع المواصفات كمصدر حقيقي للحقيقة. يبقيان الاثنان متزامنين، بحيث يمكن لمهندس الواجهة الخلفية العمل في OpenAPI الخام بينما يعمل مهندس المنتج على اللوحة، ويقومان بتحرير نفس العقد.

يدعم وضع المواصفات أولاً أيضًا مزامنة Git ثنائية الاتجاه: تعيش المواصفات في مستودعك كملف حقيقي، وتتدفق التغييرات في كلا الاتجاهين، وينتقل تصميم واجهة برمجة التطبيقات (API) الخاصة بك عبر نفس طلبات السحب (pull requests) والمراجعة مثل الكود الخاص بك. هذه هي الخاصية الأصلية لـ Git التي يقدرها مستخدمو برونو، وتطبق على العقد بدلاً من مجموعة من الطلبات. الآليات الكاملة موجودة في وثائق وضع المواصفات أولاً.

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

الاختيار حسب نضج الفريق

طريقة بسيطة للقرار: طابق الأداة مع مرحلة واجهة برمجة التطبيقات (API) في دورتها الحياتية، وليس مع تفضيل.

• فردي أو فريق صغير، يستهلك واجهات برمجة التطبيقات (APIs) في الغالب. نهج الطلبات أولاً يكفي. نموذج برونو المحلي أولاً لا يعيق طريقك، ولا تتحمل عبء صيانة عقد رسمي لا تحتاجه.
• فريق نامٍ يقوم بشحن واجهات برمجة التطبيقات (APIs) الخاصة به. هذه هي نقطة التحول. بمجرد أن يعتمد فريق ثانٍ على نقاط النهاية الخاصة بك، تتوقف المجموعة غير الرسمية عن التوسع ويبدأ العقد الصريح في توفير دورات المراجعة وأخطاء التكامل لك.
• منظمة ناضجة لديها واجهات برمجة تطبيقات (APIs) عامة أو داخلية عديدة. يصبح نهج التصميم أولاً مطلوبًا بشكل فعال. تصبح المواصفات حوكمة وتوثيقًا وتأهيلًا للموظفين دفعة واحدة، وتحافظ أداة مبنية على OpenAPI مع مزامنة Git على صدقها.

القراءة الصادقة حول برونو الطلبات أولاً مقابل التصميم أولاً هي أن النضج، وليس الذوق، هو الذي يحدد عادة. تميل الفرق إلى البدء بالطلبات أولاً وتتطور إلى التصميم أولاً عندما تصبح واجهات برمجة التطبيقات (APIs) الخاصة بها عقودًا يعتمد عليها الآخرون.

الأسئلة الشائعة

هل برونو يعتمد على الطلبات أولاً أم التصميم أولاً؟

برونو يعتمد على الطلبات أولاً. نموذجه الأساسي هو إنشاء الطلبات وتنظيمها وإرسالها مخزنة كملفات نصية عادية، وهو مثالي لاستكشاف واجهات برمجة التطبيقات (APIs) الموجودة واختبارها. لا يركز على تأليف عقد OpenAPI قبل بناء واجهة برمجة التطبيقات (API).

هل يمكنني القيام بعمل تصميم أولاً في برونو؟

ليس بشكل أصلي بالطريقة التي تقوم بها أداة تركز على المواصفات. يركز برونو على الطلبات بدلاً من المصمم المرئي أو مستند OpenAPI كمصدر للحقيقة. إذا كنت بحاجة إلى تعريف ومراجعة عقد قبل الكود، فإن أداة تعتمد على التصميم أولاً ومبنية على OpenAPI تناسب هذه المهمة بشكل أفضل.

هل يجب علي التخلي عن التوافق مع Git للانتقال إلى التصميم أولاً؟

لا. الخاصية الأصلية لـ Git، والملفات النصية العادية في مستودعك، والفروقات القابلة للقراءة، والمراجعة عبر طلبات السحب (PRs)، يمكن تطبيقها على المواصفات نفسها. يحافظ وضع المواصفات أولاً في Apidog على مستند OpenAPI في مستودعك بمزامنة ثنائية الاتجاه، لذا فإن التصميم أولاً لا يعني التخلي عن Git.