مقدمة

tsoa-next هو استمرار الأصلي tsoa مشروع، بناء على الأساس المستقر الذي أنشأه هناك لوك أوتري والمساهمون. وهو إطار متكامل OpenAPI تجميع لبناء Node.js تطبيقات جانب الخادم باستخدام TypeScript. يمكن أن تستهدف أُطراً مُعبرة، وهابي، وكوا، وأكثر في الوقت الحاضر. tsoa-next والتطبيقات مؤمنة من النوع عن طريق التقصير والتعامل مع التثبت من عدمه.

في الأدلة الواردة أدناه tsoa عادة ما يشير إلى CLI القيادة والهيكل الأساسي tsoa-next استمر

الهدف

• TypeScript المتحكمون والنماذج كمصدر واحد للحقيقة
• A valid OpenAPI (سابقا) Swaggerالمواصفات (2.0 أو 3.0) متولدة من متحكميك ونماذجك، بما في ذلك:
  • المسارات (مثلاً GET /Users)
  • التعاريف القائمة على أساس TypeScript الوصلات البينية (العارضات)
  • البارامترات/الممتلكات النموذجية المميزة حسب الاقتضاء أو الاختيارية على أساس TypeScript (على سبيل المثال، بلدي Property)؟ الخيط اختياري في OpenAPI العينة
  • jsDoc supported for object descriptions (most other metadata can be inferred from TypeScript الأنواع
• تولد الدروب للخيارات المتوسطة
  • Express.. Hapiو Koa ويمكن حالياً دعم الإطارات الوسيطة الأخرى باستخدام نموذج معالج بسيط
  • المصادقة على الجرعة البحرية

الفلسفة

• إعادة تشغيل TypeScript نوع الشروح لتوليد البيانات الفوقية للبروتوكول الاختياري إذا أمكن
• إذا كانت الشروح من النوع العادي ليست طريقة مناسبة للتعبير عن البيانات الفوقية، استخدام المصممين
• Use jsdoc for pure text metadata (e.g. endpoint descriptions)
• الحد الأدنى من الغليان
• النماذج هي أفضل طريقة لتمثيلها بالوصلات البينية (هيكل البيانات المشروطة)، ولكن يمكن أيضاً تمثيلها بالصفوف
• التحقق من وقت العمل tsoa-next ينبغي أن تتصرف بأكبر قدر ممكن من الدقة في المواصفات التي تولدت OpenAPI 2/3 Schema يصف. وتوضح أي اختلافات في منطق التصديق بتحذيرات قطع الأشجار أثناء توليد OpenAPI المواصفات و/أو الطرق.
  • يرجى ملاحظة ذلك بتمكينها من ذلك OpenAPI 3 أنت تُقلّلُ إلى أدنى حدّ من فرصِ المصادقة المتباينةِ منذ OpenAPI 3 لديه خدوش أكثر تعبيراً

Contributors

No contributors

Changelog

No recent changes