پرامپت برای طراحی API
طراحی REST: endpointها، JSON نمونه، خطاها، auth و versioning — قبل از کدنویسی.
مناسب برای: بکاند دولوپر و لید فنی
این پرامپت چه کاری انجام میدهد؟
شروع کد بدون قرارداد API فرانت و بک را desync میکند. این پرامپت {{DOMAIN}} و {{FEATURES}} را میگیرد و لیست endpoint، نمونه request/response، status code، auth و versioning میسازد.
برای شروع بکاند، مستندسازی و همترازی تیم. سپس sql-query برای persistence و code-review بعد از پیادهسازی.
GraphQL vs REST را اگر مخلوط نخواهید در FEATURES REST بگویید. جایگزین load test و security audit نیست.
خود پرامپت
نسخه فعال را کپی یا اجرا کن
تو معمار API هستی. برای این محصول یک API طراحی کن. محصول / دامنه: {{DOMAIN}} قابلیتهای اصلی: {{FEATURES}} خروجی: 1) لیست Endpointها (method + path + توضیح) 2) نمونه Request/Response JSON برای ۲ endpoint مهم 3) کدهای وضعیت و خطای استاندارد 4) نکات احراز هویت و محدودیت نرخ 5) پیشنهاد نسخهبندی (versioning) محدودیتها: {{CONSTRAINTS}}
چطور شخصیسازی کنی
- {{DOMAIN}} را یک خط محصول + کاربر.
- {{FEATURES}} را CRUD و flow اصلی لیست کنید.
- در {{CONSTRAINTS}} auth، rate limit و نسخه API را بنویسید.
- اگر idempotency برای payment لازم است بگویید.
- JSON نمونه را با فرانت validate کنید.
جدول متغیرهای پرامپت
هر متغیر را با مثال خوب پر کنید؛ مثال بد نشان میدهد چه چیزی خروجی را خراب میکند.
| متغیر | معنا | مثال خوب | مثال بد |
|---|---|---|---|
| {{DOMAIN}} | دامنه محصول | رزرو نوبت کلینیک | اپ |
| {{FEATURES}} | قابلیتهای اصلی | ثبت نوبت، لیست پزشکان، لغو، یادآور | همه چیز |
| {{CONSTRAINTS}} | محدودیتهای فنی: auth، rate limit، نسخه | JWT، 100 req/min، REST v1 | خالی |
از کپی تا نتیجه؛ قدمبهقدم
- ۱FEATURES را به resourceهای REST نگاشت کنید.
- ۲۲ endpoint مهم را با JSON نمونه validate کنید.
- ۳خطاها و auth را با تیم همتراز کنید.
- ۴implementation را code-review کنید.
- ۵کوئریهای دیتابیس را با sql-query طراحی کنید.
ورودی ضعیف در برابر ورودی قوی
ضعیف
API برای اپ من طراحی کن
قوی
دامنه: رزرو نوبت کلینیک قابلیتها: CRUD نوبت، لیست پزشکان، احراز بیمار با OTP CONSTRAINTS: JWT، ۱۰۰ req/min، REST v1
بدون دامنه و قابلیت، endpointهای تکراری و بدون خطای استاندارد.
سناریوی کامل
هدف: قرارداد REST برای MVP فروشگاه آنلاین
ورودی پرشده
دامنه: فروشگاه پوشاک کوچک قابلیتها: محصولات، سبد، checkout ساده، وضعیت سفارش CONSTRAINTS: JWT Bearer، rate limit ۱۰۰ req/min، prefix /v1
خروجی مورد انتظار
POST /v1/appointments — body: {clinicId, patientPhone, slotId} → 201 {id, status: pending} GET /v1/appointments/{id} → 200 {…} خطا: 400 validation، 401 unauthorized، 409 slot_taken — شکل یکسان {code, message, field?} Auth: JWT Bearer؛ rate limit پیشنهادی ۱۰۰ req/min برای POST. Versioning: prefix /v1؛ breaking change → /v2.
قدم بعد: JSON را با فرانت share کنید؛ sql-query برای گزارش سفارش؛ code-review بعد از پیادهسازی.
نمونه ورودی
دامنه: رزرو نوبت کلینیک قابلیتها: CRUD نوبت، لیست پزشکان، OTP بیمار، لغو
نمونه خروجی
POST /v1/appointments … GET /v1/doctors … 401/409 shapes JWT patient token versioning v1
چه زمانی از این پرامپت استفاده کنی
- شروع بکاند جدید
- همترازی فرانت و بک
- مستندسازی قرارداد API
- بازبینی فنی
اشتباهات رایج
- ندادن دامنه و نقش کاربران
- مخلوط کردن GraphQL و REST بدون تصمیم
- فراموش کردن خطاها
- بدون نمونه JSON
محدودیتها و موارد نامناسب
- بدون FEATURES endpoint تکراری میشود.
- مقیاس و SLA را پوشش نمیدهد.
- جایگزین OpenAPI tooling و penetration test نیست.
- دامنه highly regulated نیاز مشاوره دارد.
ادامه در دسته برنامهنویسی یا بازگشت به کتابخانه پرامپتها.
این پرامپت برات مفید بود؟
این پرامپت یا پرامپت مرتبط؟
- پرامپت بررسی و ریویو کد
این صفحه: طراحی قرارداد قبل از کد
آن پرامپت: بازبینی implementation
- پرامپت ساخت کوئری SQL
این صفحه: سطح API
آن پرامپت: کوئریهای پشت endpoint
پرامپتهای مرتبط
سؤالات پرتکرار
GraphQL میدهد؟+
پیشفرض REST است؛ اگر GraphQL میخواهید در FEATURES صریح بنویسید.
OpenAPI spec؟+
بخواهید «خروجی YAML OpenAPI 3» در اجرای دوم.
موبایل و وب یک API؟+
بله؛ نقشها را در FEATURES تفکیک کنید.
این پرامپت را با GPT، Claude و Gemini همزمان اجرا کن و بهترین پاسخ را انتخاب کن
در حالت Compare Mode همان پرامپت را یکبار میفرستی و پاسخ سه مدل را کنار هم میبینی — بدون کپیکردن مجدد یا جابهجایی بین تبها.
یا به کتابخانه پرامپتهای آماده برگرد.