REST API कैसे बनाएं: डिज़ाइन, सुरक्षा और डिप्लॉयमेंट

REST API बनाने के लिए, उन रिसोर्स की सूची बनाएं जिन्हें आपका ऐप मैनेज करता है (users, orders, bookings), हर एक को /orders और /orders/{id} जैसा URL दें, और कार्यों के लिए HTTP मेथड इस्तेमाल करें: पढ़ने के लिए GET, बनाने के लिए POST, अपडेट करने के लिए PATCH, हटाने के लिए DELETE। सार्थक स्टेटस कोड के साथ JSON लौटाएं, हर इनपुट को वैलिडेट करें, सर्वर पर ऑथेंटिकेशन और हर रिकॉर्ड के लिए अनुमति जाँच ज़रूरी करें, और लिस्ट को पेजिनेट करें। फिर endpoints का दस्तावेज़ बनाएं और API को HTTPS के पीछे डिप्लॉय करें।

यह गाइड डिज़ाइन के फैसले, रूट के एक उदाहरण सेट, AI ऐप बिल्डर के लिए प्रॉम्प्ट, और उन गलतियों को कवर करती है जिनसे सुरक्षा में छेद होते हैं। अगर APIs आपके लिए नए हैं, तो API क्या है से शुरू करें।

REST API कब चाहिए

• आपके वेब फ्रंटएंड को सर्वर से डेटा सेव और लोड करना है
• मोबाइल ऐप, पार्टनर या ऑटोमेशन टूल को आपके डेटा तक पहुँच चाहिए
• दूसरी सर्विसेज़ आपको इवेंट भेजती हैं (webhooks)
• आप फ्रंटएंड और बैकएंड टीमों के बीच काम बाँट रहे हैं

REST सबसे आम स्टाइल है, लेकिन अकेला विकल्प नहीं। REST बनाम GraphQL बताता है कि एक लचीला क्वेरी endpoint कब बेहतर बैठता है।

पहले डिज़ाइन: रिसोर्स और रूट

अपने ऐप के नाउन और लोग उनके साथ क्या करते हैं, यह लिखें। एक सरल booking ऐप के लिए:

ये create, read, update और delete पर मैप होते हैं; देखें CRUD क्या है। कुछ उपयोगी नियम:

• URL में बहुवचन नाउन, कोई क्रिया नहीं: /bookings, /getBookings नहीं।
• स्वामित्व स्पष्ट करने के लिए सिर्फ़ एक स्तर का नेस्टिंग: /bookings/{id}/notes।
• CRUD से अलग कार्य sub-resources हो सकते हैं: POST /bookings/{id}/cancel एक जादुई PATCH से साफ़ है।
• फ़ील्ड के नाम में एकरूपता, जैसे हर जगह created_at।

स्टेटस कोड और एरर

मानक HTTP कोड इस्तेमाल करें ताकि क्लाइंट टेक्स्ट पढ़े बिना समझ सके कि क्या हुआ:

एरर एक ही सुसंगत JSON आकार में लौटाएं, जैसे {"error": {"code": "slot_taken", "message": "That time is no longer available."}}, और रिस्पॉन्स में कभी stack trace या database एरर न डालें।

विकल्प और ट्रेड-ऑफ़

चरण-दर-चरण

1. ऊपर बताए अनुसार रिसोर्स और रूट सूचीबद्ध करें, और हर रूट को कौन कॉल कर सकता है यह भी।
2. अपने database में ज़रूरी फ़ील्ड और संबंधों के साथ डेटा मॉडल बनाएं।
3. पहले read रूट बनाएं, फिर create, update और delete।
4. हर write पर इनपुट वैलिडेट करें एक schema library से: ज़रूरी फ़ील्ड, टाइप, लंबाई, अनुमत मान। अज्ञात फ़ील्ड अस्वीकार करें।
5. ऑथेंटिकेशन जोड़ें, फिर हर रिकॉर्ड पर ऑथराइज़ेशन: /bookings/42 लोड करते समय जाँचना होगा कि booking 42 कॉलर की है, सिर्फ़ यह नहीं कि कोई लॉग इन है।
6. हर लिस्ट को पेजिनेट करें और पेज का आकार सीमित करें।
7. लॉग इन और महंगे रूट पर रेट लिमिट लगाएं। देखें रेट लिमिटिंग।
8. CORS तभी सेट करें जब दूसरे डोमेन के browsers को API कॉल करनी हो, और वे origins साफ़-साफ़ लिखें। CORS एरर कैसे ठीक करें में वे एरर समझाए गए हैं जो आपको दिखेंगे।
9. हर रूट के लिए दस्तावेज़ और टेस्ट लिखें, विफलता के मामलों सहित।
10. डिप्लॉय करें: secrets environment variables में, HTTPS, लॉग और हेल्थ चेक के साथ।

अपने AI बिल्डर को दिए जाने वाले प्रॉम्प्ट

स्कैफ़ोल्ड:

bookings के लिए REST API बनाओ, इन रूट के साथ: GET /api/health, GET /api/bookings (पेजिनेटेड, प्रति पेज अधिकतम 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id। डेटा हमारे database में स्टोर करो। request body को schema library से वैलिडेट करो और अज्ञात फ़ील्ड अस्वीकार करो। JSON एरर {"error": {"code", "message"}} के रूप में लौटाओ, सही स्टेटस कोड के साथ (400, 401, 403, 404, 409)। सीक्रेट्स environment variables में रखो।

सुरक्षा:

हर bookings रूट पर लॉग इन ज़रूरी करो। हर read, update और delete पर सर्वर पर जाँचो कि booking मौजूदा उपयोगकर्ता की है; न हो तो 404 लौटाओ। request body से user ID या roles कभी स्वीकार न करो। POST /api/bookings को प्रति उपयोगकर्ता 20 प्रति मिनट पर सीमित करो। सर्वर पर एरर लॉग करो, लेकिन stack trace कभी न लौटाओ।

दस्तावेज़:

इन रूट का OpenAPI विवरण लिखो, और हर रूट के उदाहरण request और response के साथ एक छोटी README।

अपने API का टेस्ट

फ्रंटएंड के बाहर से टेस्ट करें, क्योंकि हमलावर भी यही करेंगे:

• हर रूट सही इनपुट के साथ काम करता है और दस्तावेज़ वाला आकार और कोड लौटाता है
• गायब या गलत फ़ील्ड पर स्पष्ट संदेश के साथ 400 मिलता है
• बिना token के हर सुरक्षित रूट पर 401 मिलता है
• उपयोगकर्ता A, उपयोगकर्ता B का रिकॉर्ड ID से माँगे तो 404 या 403 मिलता है
• लिस्ट पेजिनेटेड है; बहुत बड़ा limit सीमित होता है
• डुप्लिकेट या टकराने वाले create पर 409 मिलता है, 500 नहीं
• रेट लिमिट पर 429 मिलता है
• एरर रिस्पॉन्स में stack trace, SQL या secrets नहीं हैं
• CORS सिर्फ़ आपके इच्छित origins को अनुमति देता है

आम गलतियाँ

• लॉग इन जाँचना, पर मालिकाना हक नहीं। सबसे आम API छेद: कोई भी लॉग इन उपयोगकर्ता ID बदलकर कोई भी रिकॉर्ड पढ़ सकता है।
• क्लाइंट पर भरोसा। request body की कीमतें, roles और user IDs बदले जा सकते हैं।
• पूरी database rows लौटाना। Password hashes और आंतरिक फ़ील्ड लीक होते हैं। तय करें कि हर रिस्पॉन्स में क्या जाएगा।
• बिना सीमा की लिस्ट। हर रिकॉर्ड के लिए एक रिक्वेस्ट पूरे ऐप को धीमा कर सकती है।
• 200 OK के अंदर एरर संदेश। क्लाइंट और मॉनिटरिंग नहीं जान पाते कि विफलता हुई।
• CORS सब कुछ अनुमत करने पर ऐसे API पर जो cookies इस्तेमाल करता है।
• कोई हेल्थ चेक या लॉग नहीं, इसलिए आउटेज के बारे में उपयोगकर्ताओं से पता चलता है।

लॉन्च से पहले की व्यापक जाँच के लिए, देखें AI से बने ऐप्स का सुरक्षा चेकलिस्ट।

Mythex में REST API बनाना

आप Mythex से अपने ऐप के हिस्से के रूप में या एक अलग सर्विस के रूप में API माँग सकते हैं। डॉक्स के REST API backend रेसिपी में एक स्टार्टर प्रॉम्प्ट है: अपना फ्रेमवर्क और रूट बताएं, स्पष्ट JSON एरर माँगें, सीक्रेट्स environment variables में रखें, और Dockerfile शामिल करें। Node, Python, C#, Java और अन्य में बने container backends Dockerfile के ज़रिए प्रकाशित होते हैं, और Mythex Publish से डिप्लॉय संभालता है (API backends)। एक प्रोजेक्ट वेबसाइट और API सर्वर साथ-साथ चला सकता है, और आप preview में उनके बीच बदल सकते हैं। Keys को प्रोजेक्ट secrets के रूप में रखें, और अगर API को database चाहिए तो चैट में माँगें। अपने API के साथ चलने वाले scheduled काम के लिए, देखें बैकग्राउंड जॉब कैसे चलाएं।

सवाल