تحديثات APIDOG لشهر مايو: ترحيل Postman أذكى، وضوابط أمان المصادقة، وتشغيل بدون صلاحيات الروت

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

عند نقل عمل واجهات برمجة التطبيقات بين الأدوات، لا ينتهي العمل بمجرد استيراد الملفات. غالباً ما تبدأ المشاكل بعد الاستيراد: إصلاح عناوين URL الأساسية، ضبط البيئات، إضافة المصادقة إلى الكود المُنشأ، والتأكد من أن مشغلات CI تعمل ضمن قيود البنية التحتية.

جرّب Apidog اليوم

في إصدار مايو، يركز Apidog على تقليل هذه الخطوات اليدوية. تشمل التحديثات: استيراد Postman بتخطيط أذكى لعناوين URL الأساسية، سياسات مؤسسة تبدأ بضوابط أمان المصادقة، تجربة وضع Spec-First دون ربط Git أولاً، تشغيل Runner كمستخدم غير جذري، وتضمين معلومات المصادقة في كود الطلب المُنشأ.

إليك ما تغير وكيف تستفيد منه عملياً.

⭐ تحديثات جديدة

📦 استيراد بيانات Postman مع تخطيط أذكى لعناوين URL الأساسية

عند استيراد مجموعات Postman، يحاول Apidog الآن اكتشاف عنوان URL أساسي مشترك بشكل موثوق، ثم يضعه في حقل عنوان URL الأساسي للوحدة المطابقة عبر البيئات ذات الصلة.

كيف تستخدمه عملياً

1. صدّر بياناتك من Postman أو استخدم مسار الاستيراد عبر Postman API.
2. استورد الملفات داخل Apidog.
3. راجع البيئات بعد الاستيراد.
4. تحقق من أن عنوان URL الأساسي المشترك تم وضعه في الحقل المناسب.
5. شغّل الطلبات مباشرة للتأكد من أن المسارات تعمل كما هو متوقع.

قبل	الآن
استيراد المجموعات من Postman. التحقق يدوياً من عناوين URL للطلبات. ملء عناوين URL الأساسية للوحدات لكل بيئة. إصلاح الطلبات المعطلة قبل الاختبار.	استيراد ملفات Postman أو استخدام Postman API. يحاول Apidog اكتشاف عناوين URL الأساسية المشتركة. توضع القيم المكتشفة في حقل عنوان URL الأساسي للوحدة المطابقة. تصبح الطلبات المستوردة أقرب للتشغيل مباشرة.

يدعم هذا التحسين كلاً من استيراد ملفات Postman المحلية والاستيراد عبر Postman API. عندما تحتوي عناوين URL للطلبات على عنوان مشترك واضح أو متغير يمكن التعرف عليه، يحاول Apidog استخراج عنوان URL الأساسي القابل للاستخدام ووضعه في تكوين البيئة المناسب.

---

🛡️ سياسات المؤسسة تبدأ بضوابط أمان المصادقة

يقدم Apidog سياسات المؤسسة كإطار حوكمة لضوابط الأمان على مستوى المؤسسة، بدءاً من أمان المصادقة.

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

خطوات مقترحة للمسؤولين

1. راجع طرق المصادقة المستخدمة في مشاريع واجهة برمجة التطبيقات.
2. حدد الحقول التي تحتوي على رموز أو مفاتيح أو بيانات اعتماد.
3. انقل القيم الحساسة إلى متغيرات أو Vault Secrets عند الحاجة.
4. فعّل القواعد المناسبة ضمن سياسات المؤسسة.
5. امنع كشف أسرار Vault كنص عادي في واجهة المستخدم عند الحاجة.

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

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

---

📝 وضع Spec-First لم يعد يتطلب إعداد Git أولاً

أصبح بإمكانك إنشاء مشروع Spec-First دون ربط مستودع Git أولاً. بعد إنشاء المشروع، يمكنك إضافة أو استيراد ملف OpenAPI عندما تكون جاهزاً.

متى يكون هذا مفيداً؟

استخدم هذا المسار إذا كنت تريد:

• تجربة سير عمل يركز على OpenAPI قبل اعتماد Git.
• مراجعة هيكل API مع الفريق مبكراً.
• جمع ملاحظات قبل تثبيت هيكل المستودع.
• إنشاء نموذج أولي للمواصفة دون إعداد كامل للبنية التحتية.

سير عمل عملي

1. أنشئ مشروع Spec-First جديداً.
2. ابدأ دون ربط Git.
3. أضف أو استورد ملف OpenAPI.
4. راجع نقاط النهاية والنماذج داخل Apidog.
5. اربط Git لاحقاً عندما يصبح سير العمل جاهزاً.

ℹ️ هذا مفيد للفرق التي تقيّم سير عمل Spec-First أو تجمع الملاحظات المبكرة قبل توحيد هيكل المستودع.

---

🔒 يمكن للمشغل Runner الآن العمل كمستخدم غير جذري

يدعم Runner الآن العمل كمستخدم غير جذري.

هذا مهم في بيئات الخادم والحاويات وCI/CD التي تمنع تشغيل العمليات كمستخدم جذري. يمكن للفرق نشر Runner بأذونات أقل مع الحفاظ على سير عمل التشغيل الآلي الحالي.

ما الذي يجب مراجعته؟

إذا كنت تستخدم Runner في بيئات مؤتمتة، راجع الآتي:

• هل سياسات الخادم تمنع تشغيل العمليات كمستخدم root؟
• هل حاويات CI/CD لديك تطبق مستخدماً غير جذري؟
• هل يحتاج Runner إلى أذونات ملفات أو مجلدات محددة؟
• هل مسارات الإخراج والسجلات قابلة للكتابة من المستخدم الجديد؟

✅ يساعد هذا التحديث على مواءمة نشر Runner مع متطلبات الأمان الداخلية دون تغيير سير عمل الاختبار العام.

---

🔐 يمكن لكود الطلب المُنشأ أن يتضمن معلومات المصادقة

عند إنشاء كود طلب من طلب API، يمكن لـ Apidog الآن تضمين معلومات المصادقة التي تم تكوينها بالفعل.

بدلاً من تصدير مقتطف ثم إضافة الرؤوس أو الرموز أو معلمات المصادقة يدوياً، يصبح الكود المُنشأ أقرب إلى طلب قابل للتشغيل مباشرة.

حالات استخدام عملية

• التحقق السريع من استدعاء API خارج الواجهة.
• مشاركة مثال قابل للتشغيل مع زميل.
• لصق الطلب داخل جلسة تصحيح أخطاء.
• مقارنة الطلب الفعلي مع تنفيذ في خدمة أخرى.

مثال على الشكل المتوقع لفكرة الطلب بعد تضمين المصادقة:

curl --request GET "https://api.example.com/users" \
  --header "Authorization: Bearer <token>" \
  --header "Content-Type: application/json"

الفكرة هنا أن المقتطف المُنشأ يعكس المزيد من التكوين الذي أعددته بالفعل داخل Apidog، بدلاً من البدء من مثال ناقص.

---

✅ تحسينات

🧩 تنفيذ نصوص CLI البرمجية أصبح أكثر تقييداً

لتقليل مخاطر تنفيذ النصوص البرمجية، تسمح واجهة سطر الأوامر CLI الآن فقط باستدعاء النصوص البرمجية من دليل "External Programs".

ما الذي يجب فعله؟

إذا كان فريقك يستخدم نصوص CLI في التشغيل الآلي:

1. راجع المسارات الحالية للنصوص.
2. تأكد من أنها موجودة ضمن دليل External Programs.
3. حدّث أي مهام CI أو سكربتات تعتمد على مسارات قديمة.
4. اختبر التنفيذ بعد التعديل.

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

---

📋 أوامر cURL المنسوخة تتضمن المزيد من تكوين الطلب

عند نسخ أمر cURL من Apidog، يتضمن الأمر المُنشأ الآن معلمات الرأس والجسم بشكل أكثر موثوقية.

هذا يجعل الأمر المنسوخ أقرب إلى الطلب الذي قمت بتكوينه داخل التطبيق.

متى تستفيد من ذلك؟

• عند تصحيح الأخطاء في الطرفية.
• عند مشاركة طلب قابل لإعادة الإنتاج.
• عند توثيق مشكلة في تذكرة دعم أو مراجعة داخلية.
• عند مقارنة سلوك Apidog مع تنفيذ آخر.

مثال:

curl --request POST "https://api.example.com/orders" \
  --header "Content-Type: application/json" \
  --data '{
    "productId": "123",
    "quantity": 2
  }'

---

🧪 خطوات الاختبار الآلي تبقى متزامنة بعد تغييرات الطريقة

عندما تتغير طريقة طلب نقطة نهاية من GET إلى POST أو PUT أو طريقة أخرى، تقوم خطوات الاختبار الآلي ذات الصلة الآن بمزامنة التكوين المحدث بدقة أكبر.

لماذا يهم هذا؟

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

الآن، بعد تعديل طريقة الطلب، تصبح خطوات الاختبار أقرب للتكوين الحالي، مما يجعل نتائج الاختبار الآلي أسهل في الوثوق بها بعد تحديثات نقاط النهاية.

---

🎲 توليد بيانات وهمية Mock Data أكثر موثوقية

يصلح هذا الإصدار عدة مشكلات في توليد بيانات Mock، بما في ذلك:

• قواعد المضاعفة multiplier rules.
• تعبيرات arrayElements.
• مشكلات التوليد الدفعي عند استخدام توليد JavaScript وتوليد Mock معاً.

أين يظهر الأثر؟

• تكامل الواجهة الأمامية والخلفية.
• توليد بيانات اختبار بكميات كبيرة.
• الاختبارات الآلية التي تعتمد على مخرجات Mock.
• التحقق من سيناريوهات متعددة دون الاعتماد على بيانات حقيقية.

يجب أن تكون مخرجات Mock الآن أكثر استقراراً وأقرب إلى القواعد التي قمت بتكوينها.

---

🐞 إصلاحات الأخطاء وتحسينات أصغر

تضمن إصدار مايو أيضاً مجموعة من الإصلاحات والتحسينات:

• تم إصلاح مشكلة عدم عرض معلمات طلب التوثيق المشترك لأمثلة افتراضية.
• تم إصلاح مشكلة فشل تصدير مشروع يحتوي على مستندات Markdown فقط ولا يحتوي على نقاط نهاية.
• تم إصلاح عدة مشكلات في توليد بيانات Mock، بما في ذلك التوليد الدفعي عند استخدام توليد JavaScript وتوليد Mock معاً، وقواعد مضاعفة الأرقام، وتعبيرات arrayElements للحد الأدنى والأقصى.
• تم إصلاح مشكلة حيث يمكن لروابط نظرة عامة المشروع الثابتة أن ترجع خطأ 500 بعد فتح روابط من مشاريع مختلفة بالتتابع.
• تم إصلاح مشكلة حيث يمكن أن تعرض الواجهة Error: Cannot read properties of null (reading 'nullable') في بعض الحالات.
• تم إصلاح مشكلة تباين قد تجعل قراءة أسماء الأمثلة المختارة في التوثيق المشترك صعبة في المظهر الفاتح.
• تم إصلاح مشكلة عدم قدرة مستخدمي Windows على استخدام AI Agent Debugger بشكل طبيعي.
• تم إصلاح مشكلة حيث يعرض حقل نص الطلب من نوع form-data الذي يحتوي على عدة ملفات مرفوعة ملفاً واحداً فقط بعد فتح التعديل الدفعي والحفظ.

---

🌟 ماذا يعني هذا عملياً؟

يركز إصدار مايو على إزالة مصادر احتكاك صغيرة لكنها مكلفة في سير عمل واجهات برمجة التطبيقات.

المجال	ما الذي يتحسن	لماذا يهم
ترحيل Postman	يتم تعيين عناوين URL الأساسية المشتركة عندما يتمكن Apidog من اكتشافها بشكل موثوق.	تنظيف يدوي أقل بعد استيراد المجموعات وتكوين البيئات.
نشر Runner	يمكن لـ Runner العمل كمستخدم غير جذري.	توافق أفضل مع سياسات الخادم والحاويات وCI/CD الأكثر صرامة.
أمان المؤسسات	تبدأ سياسات المؤسسة بضوابط أمان المصادقة.	يمكن للمسؤولين تقليل انكشاف بيانات الاعتماد الخام في سير عمل المصادقة.
سير عمل Spec-First	لم تعد مشاريع Spec-First تتطلب ربط Git قبل الاستخدام.	يمكن للفرق تجربة العمل الذي يركز على OpenAPI قبل إعداد سير عمل المستودع.
مشاركة الطلبات	تتضمن الأكواد المُنشأة ومخرجات cURL المزيد من تكوين الطلب.	الأمثلة أسهل في التشغيل وإعادة الإنتاج والمشاركة.
الاختبار والمحاكاة Mocking	تتزامن خطوات الاختبار بدقة أكبر ويكون توليد بيانات Mock أكثر استقراراً.	تقضي الفرق وقتاً أقل في مطاردة انحراف التكوين وبيانات الاختبار غير المتوقعة.

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

---

💬 انضم إلى المحادثة

تواصل مع مهندسي واجهة برمجة التطبيقات وفريق Apidog:

• انضم إلى مجتمعنا على Discord للمناقشات والدعم في الوقت الفعلي.
• شارك في مجتمعنا على Slack للمحادثات التقنية.
• تابعنا على X (Twitter) للحصول على أحدث التحديثات.

ملاحظة: للحصول على التفاصيل الكاملة لجميع التحديثات، تحقق من سجل تغييرات Apidog.

مع خالص التقدير،

فريق Apidog