REST API کیسے بنائیں: ڈیزائن، سیکیورٹی اور ڈیپلائمنٹ

REST API بنانے کے لیے، ان ریسورسز کی فہرست بنائیں جنہیں آپ کی ایپ منظم کرتی ہے (users، orders، bookings)، ہر ایک کو /orders اور /orders/{id} جیسا URL دیں، اور کاموں کے لیے HTTP methods استعمال کریں: پڑھنے کے لیے GET، بنانے کے لیے POST، اپڈیٹ کے لیے PATCH، اور حذف کرنے کے لیے DELETE۔ JSON واپس کریں جس کے ساتھ بامعنی status codes ہوں، ہر ان پٹ validate کریں، سرور پر authentication اور ہر record کے لیے اجازت کی جانچ لازمی کریں، اور فہرستوں کو paginate کریں۔ پھر endpoints کی دستاویز بنائیں اور API کو HTTPS کے پیچھے deploy کریں۔

یہ گائیڈ ڈیزائن کے فیصلے، routes کی ایک عملی مثال، AI app builder کے لیے prompts، اور وہ غلطیاں بتاتی ہے جن سے سیکیورٹی کے سوراخ بنتے ہیں۔ اگر APIs آپ کے لیے نئی ہیں تو API کیا ہے سے شروع کریں۔

REST API کب چاہیے

• آپ کے web frontend کو سرور سے ڈیٹا محفوظ اور حاصل کرنا ہو
• کوئی mobile app، partner یا automation tool آپ کے ڈیٹا تک رسائی چاہتا ہو
• دوسری سروسز آپ کو events بھیجیں (webhooks)
• آپ کام کو frontend اور backend ٹیموں میں بانٹ رہے ہوں

REST سب سے عام انداز ہے، لیکن واحد انداز نہیں۔ REST بمقابلہ GraphQL بتاتا ہے کہ ایک لچکدار query endpoint کب بہتر ہے۔

پہلے ڈیزائن کریں: ریسورسز اور routes

اپنی ایپ کے اسما اور لوگ ان کے ساتھ کیا کرتے ہیں، یہ لکھ لیں۔ ایک سادہ booking ایپ کے لیے:

یہ create، read، update اور delete پر منطبق ہوتے ہیں؛ دیکھیں CRUD کیا ہے۔ یہ اصول اپنانے کے قابل ہیں:

• URLs میں جمع اسم، فعل نہیں: /bookings، نہ کہ /getBookings۔
• ملکیت واضح کرنے کے لیے صرف ایک سطح کا nesting: /bookings/{id}/notes۔
• CRUD کے علاوہ کارروائیاں sub-resources ہو سکتی ہیں: POST /bookings/{id}/cancel کسی جادوئی PATCH سے واضح ہے۔
• fields کے لیے یکساں نام، جیسے ہر جگہ created_at۔

Status codes اور errors

معیاری HTTP codes استعمال کریں تاکہ کلائنٹ متن پارس کیے بغیر جان سکے کہ کیا ہوا:

errors ایک یکساں JSON شکل میں واپس کریں، مثلاً {"error": {"code": "slot_taken", "message": "یہ وقت اب دستیاب نہیں۔"}}، اور جواب میں کبھی stack traces یا database errors شامل نہ کریں۔

اختیارات اور تجارتی فیصلے

قدم بہ قدم

1. اوپر بتائے گئے مطابق ریسورسز اور routes کی فہرست بنائیں، جس میں یہ بھی ہو کہ ہر route کو کون کال کر سکتا ہے۔
2. اپنے database میں ڈیٹا ماڈل کریں، جن fields اور تعلقات کی ضرورت ہے انہی کے ساتھ۔
3. پہلے read routes بنائیں، پھر create، update اور delete۔
4. ہر write پر schema library کے ساتھ ان پٹ validate کریں: لازمی fields، types، لمبائی، اجازت شدہ قدریں۔ نامعلوم fields رد کریں۔
5. Authentication شامل کریں، پھر ہر record کے لیے authorisation: /bookings/42 لوڈ کرتے وقت یہ چیک ہونا چاہیے کہ booking 42 کال کرنے والے کی ہے، نہ کہ صرف یہ کہ کوئی لاگ ان ہے۔
6. ہر فہرست کو paginate کریں اور page کا سائز محدود کریں۔
7. لاگ ان اور مہنگے routes کی rate limit لگائیں۔ دیکھیں rate limiting۔
8. CORS صرف اس صورت میں ترتیب دیں جب دوسرے domains کے browsers کو API کال کرنی ہو، اور وہ origins واضح طور پر لکھیں۔ CORS errors کیسے ٹھیک کریں میں وہ errors بیان ہیں جو آپ دیکھیں گے۔
9. ہر route کے لیے docs اور tests لکھیں، ناکامی کے معاملات سمیت۔
10. Deploy کریں، secrets environment variables میں رکھیں، HTTPS، logs اور health check کے ساتھ۔

AI builder کو دینے کے prompts

Scaffold:

bookings کے لیے یہ routes کے ساتھ REST API بناؤ: GET /api/health، GET /api/bookings (paginated، زیادہ سے زیادہ 50 فی page)، POST /api/bookings، GET /api/bookings/:id، PATCH /api/bookings/:id، DELETE /api/bookings/:id۔ ڈیٹا ہمارے database میں محفوظ کرو۔ request bodies کو schema library سے validate کرو اور نامعلوم fields رد کرو۔ errors JSON میں {"error": {"code", "message"}} کی شکل میں درست status codes (400، 401، 403، 404، 409) کے ساتھ واپس کرو۔ secrets environment variables میں رکھو۔

Security:

bookings کے ہر route پر لاگ ان لازمی کرو۔ ہر read، update اور delete پر سرور پر چیک کرو کہ booking موجودہ صارف کی ہے؛ اگر نہیں تو 404 واپس کرو۔ request body سے user IDs یا roles کبھی قبول نہ کرو۔ POST /api/bookings کو فی صارف 20 فی منٹ تک محدود کرو۔ errors سرور پر لاگ کرو اور stack traces واپس نہ کرو۔

Docs:

ان routes کی OpenAPI وضاحت لکھو، اور ہر route کے لیے مثال کی requests اور responses کے ساتھ ایک مختصر README بناؤ۔

اپنی API کی جانچ

فرنٹ اینڈ سے باہر سے ٹیسٹ کریں، کیونکہ حملہ آور بھی یہی کریں گے:

• ہر route درست ان پٹ کے ساتھ کام کرے اور دستاویزی شکل اور code واپس کرے
• لاپتا یا غلط fields پر واضح پیغام کے ساتھ 400 آئے
• ہر محفوظ route پر token نہ ہونے سے 401 آئے
• صارف A کا صارف B کا record ID سے مانگنا 404 یا 403 دے
• فہرستیں paginated ہوں؛ بہت بڑی limit محدود ہو
• ڈپلیکیٹ یا متضاد create پر 409 آئے، 500 نہیں
• rate limits پر 429 آئے
• error responses میں stack traces، SQL یا secrets نہ ہوں
• CORS صرف ان origins کو اجازت دے جو آپ چاہتے ہیں

عام غلطیاں

• لاگ ان چیک کرنا مگر ملکیت نہ دیکھنا۔ API کا سب سے عام سوراخ: کوئی بھی لاگ ان صارف ID بدل کر کسی بھی record کو پڑھ سکتا ہے۔
• کلائنٹ پر بھروسہ۔ request body میں قیمتیں، roles اور user IDs تبدیل کیے جا سکتے ہیں۔
• پورے database rows واپس کرنا۔ password hashes اور اندرونی fields لیک ہو جاتے ہیں۔ طے کریں کہ ہر response میں کیا شامل ہو۔
• بے حد فہرستیں۔ ہر record کی ایک درخواست پوری ایپ کو سست کر سکتی ہے۔
• جواب میں error پیغام کے ساتھ 200 OK۔ کلائنٹ اور monitoring نہیں جان سکتے کہ ناکامی ہوئی۔
• CORS کا ہر چیز کی اجازت دینا ایک ایسی API پر جو cookies استعمال کرتی ہے۔
• کوئی health check یا logs نہیں، اس لیے outages کا علم صارفین کی شکایت سے ہوتا ہے۔

لانچ سے پہلے وسیع جائزے کے لیے، دیکھیں AI سے بنی ایپس کی سیکیورٹی چیک لسٹ۔

Mythex میں REST API بنانا

آپ Mythex سے اپنی ایپ کے حصے کے طور پر یا علیحدہ سروس کے طور پر API مانگ سکتے ہیں۔ docs کی recipe REST API backend میں ایک starter prompt ہے: اپنا فریم ورک اور routes بتائیں، واضح JSON errors مانگیں، secrets environment variables میں رکھیں، اور Dockerfile شامل کریں۔ Node، Python، C#، Java اور دیگر میں container backends Dockerfile کے ذریعے publish ہوتے ہیں، اور Mythex Publish سے deploy سنبھالتا ہے (API backends)۔ ایک پروجیکٹ ساتھ ساتھ website اور API server چلا سکتا ہے، اور آپ preview میں ان کے درمیان سوئچ کر سکتے ہیں۔ Project secrets کے طور پر keys محفوظ کریں، اور اگر API کو database چاہیے تو چیٹ میں مانگیں۔ API کے گرد scheduled کام کے لیے، دیکھیں background jobs کیسے چلائیں۔

سوالات