REST API कसा बनवायचा: डिझाइन, सुरक्षा आणि डिप्लॉयमेंट
REST API बनवण्यासाठी तुमच्या अॅपमध्ये व्यवस्थापित होणाऱ्या रिसोर्सेसची यादी करा (युजर्स, ऑर्डर्स, बुकिंग्ज), प्रत्येकाला /orders आणि /orders/{id} सारखा URL द्या, आणि क्रियांसाठी HTTP पद्धती वापरा: वाचण्यासाठी GET, तयार करण्यासाठी POST, अपडेटसाठी PATCH, काढण्यासाठी DELETE. अर्थपूर्ण स्टेटस कोड सह JSON परत द्या, प्रत्येक इनपुट व्हॅलिडेट करा, सर्व्हरवर ऑथेंटिकेशन आणि प्रत्येक रेकॉर्डसाठी परवानगी तपासणी लागू करा, आणि यादीचे पेजिनेशन करा. मग एंडपॉइंट्सचे डॉक्युमेंटेशन लिहा आणि API HTTPS मागे डिप्लॉय करा.
हे मार्गदर्शक डिझाइनचे निर्णय, काही व्यवहार्य रूट्स, AI अॅप बिल्डरसाठी प्रॉम्प्ट्स आणि सुरक्षा त्रुटी निर्माण करणाऱ्या चुका स्पष्ट करते. API तुमच्यासाठी नवीन असतील तर API म्हणजे काय यापासून सुरुवात करा.
REST API कधी लागतो
- तुमच्या वेब फ्रंटएंडला सर्व्हरवर डेटा सेव्ह आणि लोड करायचा असतो
- मोबाइल अॅप, पार्टनर किंवा ऑटोमेशन टूलला तुमच्या डेटाचा अ‍ॅक्सेस हवा असतो
- इतर सेवा तुम्हाला इव्हेंट्स पाठवतात (वेबहुक्स)
- तुम्ही फ्रंटएंड आणि बॅकएंड टीममध्ये काम विभागत आहात
REST हा सर्वात सामान्य प्रकार आहे, पण एकमेव नाही. REST विरुद्ध GraphQL मध्ये एकच लवचिक क्वेरी एंडपॉइंट कधी योग्य ठरतो ते स्पष्ट केले आहे.
आधी डिझाइन करा: रिसोर्सेस आणि रूट्स
तुमच्या अॅपमधील नाम (nouns) आणि लोक त्यांच्यासोबत काय करतात ते लिहून ठेवा. साध्या बुकिंग अॅपसाठी:
| पद्धत | रूट | काय करते | यशस्वी कोड |
|---|---|---|---|
GET | /api/bookings | कॉलरची बुकिंग्ज यादी करते (पेजिनेटेड) | 200 |
POST | /api/bookings | नवीन बुकिंग तयार करते | 201 |
GET | /api/bookings/{id} | एक बुकिंग मिळवते | 200 |
PATCH | /api/bookings/{id} | काही फील्ड्स बदलते | 200 |
DELETE | /api/bookings/{id} | बुकिंग रद्द करते | 204 |
GET | /api/health | मॉनिटरिंगसाठी हेल्थ तपासणी | 200 |
हे क्रिएट, रीड, अपडेट आणि डिलीट यांच्याशी जुळतात; CRUD म्हणजे काय ते पहा. उपयुक्त नियम:
- URL मध्ये अनेकवचनी नाम, क्रियापद नाही:
/bookings,/getBookingsनाही. - मालकी स्पष्ट करण्यासाठी फक्त एक पातळी नेस्टिंग करा:
/bookings/{id}/notes. - CRUD नसलेल्या क्रिया सब-रिसोर्स म्हणून ठेवा:
POST /bookings/{id}/cancelहे जादुई PATCH पेक्षा स्पष्ट आहे. - फील्ड्सची सुसंगत नावे ठेवा, जसे सर्वत्र
created_at.
स्टेटस कोड आणि एरर
क्लायंटला मजकूर न वाचता काय झाले ते कळावे म्हणून प्रमाणित HTTP कोड वापरा:
| कोड | अर्थ | कधी वापरावा |
|---|---|---|
| 200 | OK | यशस्वी वाचन किंवा अपडेट |
| 201 | Created | POST ने काहीतरी तयार केले |
| 204 | No Content | यश, पण परत देण्यासारखे काही नाही |
| 400 | Bad Request | इनपुट व्हॅलिडेशनमध्ये अयशस्वी |
| 401 | Unauthorized | लॉगिन नाही किंवा टोकन चुकीचे |
| 403 | Forbidden | लॉगिन आहे, पण परवानगी नाही |
| 404 | Not Found | अस्तित्वात नाही, किंवा कॉलरला ते अस्तित्वात असल्याचे कळू नये |
| 409 | Conflict | डुप्लिकेट, किंवा स्लॉट आधीच बुक आहे |
| 429 | Too Many Requests | रेट लिमिट ओलांडली |
| 500 | Server Error | तुमच्या बाजूला काहीतरी बिघडले |
एरर्स एकाच सुसंगत JSON स्वरूपात परत द्या, उदाहरणार्थ {"error": {"code": "slot_taken", "message": "ती वेळ आता उपलब्ध नाही."}}, आणि प्रतिसादांमध्ये कधीही स्टॅक ट्रेस किंवा डेटाबेस एरर्स टाकू नका.
पर्याय आणि तडजोडी
| निर्णय | सोपी निवड | पर्याय |
|---|---|---|
| API कुठे राहते | तुमच्या वेब फ्रेमवर्कमधील API रूट्स | वेगळी API सेवा, अनेक क्लायंट्ससाठी किंवा वेगळ्या भाषेसाठी उपयुक्त |
| ऑथेंटिकेशन | तुमच्या स्वतःच्या वेब अॅपसाठी सेशन कुकीज | मोबाइल अॅप्स आणि तृतीय पक्षांसाठी टोकन्स (bearer tokens किंवा API keys) |
| पेजिनेशन | ?page=2&limit=20 | कर्सर-आधारित (?after=...), मोठ्या आणि बदलणाऱ्या यादींसाठी स्थिर |
| व्हर्जनिंग | बाहेरचे युजर्स येईपर्यंत काहीच नाही | इतर अवलंबून असतील तर पथात /v1/ |
| डॉक्स | रूट्सची यादी असलेली README | OpenAPI स्पेक, ज्यावरून टूल्स इंटरॅक्टिव्ह डॉक्स आणि क्लायंट कोड तयार करू शकतात |
टप्प्याटप्प्याने
- वरीलप्रमाणे रिसोर्सेस आणि रूट्सची यादी करा, कोण कॉल करू शकतो त्यासह.
- तुमच्या डेटाबेसमध्ये आवश्यक फील्ड्स आणि संबंधांसह डेटा मॉडेल करा.
- आधी रीड रूट्स बनवा, मग तयार करणे, अपडेट आणि डिलीट.
- प्रत्येक राइटवर स्कीमा लायब्ररीने इनपुट व्हॅलिडेट करा: आवश्यक फील्ड्स, प्रकार, लांबी, अनुमत मूल्ये. अनोळखी फील्ड्स नाकारा.
- ऑथेंटिकेशन जोडा, मग प्रति-रेकॉर्ड परवानगी:
/bookings/42उघडताना कोणी लॉगिन केले आहे इतकेच नव्हे, तर बुकिंग 42 कॉलरचे आहे का ते तपासा. - प्रत्येक यादीचे पेजिनेशन करा आणि पेज आकाराला मर्यादा ठेवा.
- लॉगिन आणि महागड्या रूट्सवर रेट लिमिट लावा. रेट लिमिटिंग पहा.
- CORS फक्त तेव्हाच सेट करा जेव्हा इतर डोमेन्सवरील ब्राउझर्सना API कॉल करावे लागतात, आणि त्या ओरिजिन्स स्पष्टपणे यादीत ठेवा. CORS एरर्स कशा दुरुस्त कराल मध्ये तुम्हाला दिसणाऱ्या एरर्स स्पष्ट केल्या आहेत.
- प्रत्येक रूटसाठी डॉक्स आणि टेस्ट्स लिहा, अपयशाच्या केसेससह.
- डिप्लॉय करा: सीक्रेट्स एन्व्हायर्नमेंट व्हेरिएबल्समध्ये, HTTPS, लॉग्ज आणि हेल्थ तपासणीसह.
तुमच्या AI बिल्डरसाठी प्रॉम्प्ट्स
स्कॅफोल्ड:
बुकिंग्जसाठी REST API बनवा, या रूट्ससह: GET /api/health, GET /api/bookings (पेजिनेटेड, प्रति पेज कमाल 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. डेटा आमच्या डेटाबेसमध्ये साठवा. रिक्वेस्ट बॉडीज स्कीमा लायब्ररीने व्हॅलिडेट करा आणि अनोळखी फील्ड्स नाकारा. JSON एरर्स {"error": {"code", "message"}} स्वरूपात, योग्य स्टेटस कोडसह (400, 401, 403, 404, 409) परत करा. सीक्रेट्स एन्व्हायर्नमेंट व्हेरिएबल्समध्ये ठेवा.
सुरक्षा:
बुकिंग्ज रूट्सपैकी प्रत्येकासाठी लॉगिन आवश्यक करा. प्रत्येक रीड, अपडेट आणि डिलीटवर सर्व्हरवर तपासा की बुकिंग सध्याच्या युजरचे आहे; नसेल तर 404 परत करा. रिक्वेस्ट बॉडीमधून युजर ID किंवा रोल्स कधीही स्वीकारू नका. POST /api/bookings ला प्रति युजर प्रति मिनिट 20 पर्यंत मर्यादा घाला. सर्व्हरवर एरर्स लॉग करा, पण स्टॅक ट्रेस परत करू नका.
डॉक्स:
या रूट्सचे OpenAPI वर्णन लिहा, आणि प्रत्येक रूटसाठी उदाहरण रिक्वेस्ट्स व प्रतिसादांसह एक छोटी README लिहा.
तुमच्या API ची चाचणी
फ्रंटएंडबाहेरून चाचणी करा, कारण हल्लेखोर तेच करतील:
- प्रत्येक रूट योग्य इनपुटसह काम करतो आणि दिलेला आकार व कोड परत देतो
- गहाळ किंवा चुकीच्या फील्ड्सवर स्पष्ट संदेशासह 400 परत येतो
- प्रत्येक संरक्षित रूटवर टोकन नसल्यास 401 परत येतो
- युजर A ने युजर B चा रेकॉर्ड ID ने मागितल्यास 404 किंवा 403 मिळतो
- यादी पेजिनेटेड आहे; मोठे
limitमर्यादित केले जाते - डुप्लिकेट किंवा विरोधाभासी तयार करण्यावर 500 नाही तर 409 परत येतो
- रेट लिमिटवर 429 परत येतो
- एरर प्रतिसादांमध्ये स्टॅक ट्रेस, SQL किंवा सीक्रेट्स नाहीत
- CORS फक्त तुमच्या इच्छित ओरिजिन्सना परवानगी देतो
सामान्य चुका
- लॉगिन तपासणे, पण मालकी न तपासणे. सर्वात सामान्य API त्रुटी: कोणताही लॉग इन युजर ID बदलून कोणताही रेकॉर्ड वाचू शकतो.
- क्लायंटवर विश्वास ठेवणे. रिक्वेस्ट बॉडीमधील किमती, रोल्स आणि युजर ID बदलता येतात.
- संपूर्ण डेटाबेस रो परत देणे. पासवर्ड हॅश आणि अंतर्गत फील्ड्स लीक होतात. प्रत्येक प्रतिसादात काय असावे ते निवडा.
- मर्यादा नसलेल्या यादी. प्रत्येक रेकॉर्डसाठी एक रिक्वेस्ट संपूर्ण अॅप मंद करू शकते.
- आत एरर संदेश असलेला
200 OK. क्लायंट आणि मॉनिटरिंगला अपयश कळत नाही. - सर्व काही परवानगी देणारे CORS, कुकीज वापरणाऱ्या API वर.
- हेल्थ चेक किंवा लॉग्ज नसणे, त्यामुळे आउटेज वापरकर्त्यांकडूनच कळतो.
लॉन्चपूर्वी व्यापक तपासणीसाठी AI ने बनवलेल्या अॅप्ससाठी सुरक्षा चेकलिस्ट पहा.
Mythex मध्ये REST API बनवणे
तुम्ही Mythex ला तुमच्या अॅपचा भाग म्हणून किंवा स्वतंत्र सेवा म्हणून API मागू शकता. डॉक्स मधील REST API बॅकएंड रेसिपीमध्ये स्टार्टर प्रॉम्प्ट आहे: तुमचा फ्रेमवर्क आणि रूट्स नमूद करा, स्पष्ट JSON एरर्स मागा, सीक्रेट्स एन्व्हायर्नमेंट व्हेरिएबल्समध्ये ठेवा, आणि Dockerfile समाविष्ट करा. Node, Python, C#, Java आणि इतर भाषांमधील कंटेनर बॅकएंड्स Dockerfile द्वारे प्रकाशित होतात, आणि Publish मधून डिप्लॉय Mythex हाताळते (API बॅकएंड्स). प्रोजेक्ट वेबसाइट आणि API सर्व्हर एकत्र चालवू शकतो, आणि प्रीव्ह्यूमध्ये दोघांमध्ये बदलू शकता. सीक्रेट्स प्रोजेक्ट सीक्रेट्स म्हणून ठेवा, आणि API ला डेटाबेस हवा असल्यास चॅटमध्ये मागा. API साठी पार्श्वभूमीतील नियोजित कामांसाठी बॅकग्राउंड जॉब्स कसे चालवायचे पहा.
प्रश्न
REST API म्हणजे काय?
REST API हा प्रोग्राम्सना HTTP द्वारे तुमच्या अॅपच्या डेटासोबत काम करण्याचा मार्ग आहे. प्रत्येक प्रकारचा डेटा हा स्वतःच्या URL असलेला रिसोर्स असतो, जसे की /orders, आणि प्रमाणित पद्धती त्यावर काम करतात: वाचण्यासाठी GET, तयार करण्यासाठी POST, अपडेटसाठी PATCH किंवा PUT, आणि काढण्यासाठी DELETE. डेटा सहसा JSON स्वरूपात पाठवला जातो.
REST API कोणत्या भाषेत बनवावा?
तुम्हाला किंवा तुमच्या टीमला जी भाषा सांभाळता येईल ती वापरा. Express किंवा Fastify सह Node.js, FastAPI सह Python, आणि C# किंवा Java फ्रेमवर्क्स सर्व चांगले काम करतात. रूट्स, स्टेटस कोड, व्हॅलिडेशन आणि ऑथेंटिकेशनचे डिझाइन नियम भाषेपेक्षा जास्त महत्त्वाचे आहेत.
REST API कसा सुरक्षित करायचा?
प्रत्येक सार्वजनिक नसलेल्या रूटसाठी ऑथेंटिकेशन ठेवा, प्रत्येक विशिष्ट रेकॉर्डचा अ‍ॅक्सेस कॉलरला आहे का ते सर्व्हरवर तपासा, सर्व इनपुट व्हॅलिडेट करा, HTTPS वापरा, विनंत्यांवर रेट लिमिट लावा, आणि सीक्रेट्स एन्व्हायर्नमेंट व्हेरिएबल्समध्ये ठेवा. क्लायंटकडून आलेल्या ID किंवा रोल्सवर कधीही विश्वास ठेवू नका.
REST API साठी वेगळा बॅकएंड लागतो का?
नेहमीच नाही. Next.js सारखे फ्रेमवर्क्स पेजेससोबत API रूट्सही देऊ शकतात. अनेक क्लायंट्स (वेब, मोबाइल, पार्टनर्स) API वापरत असतील, किंवा त्याला स्वतःची भाषा किंवा स्केलिंग हवे असेल, तर वेगळी API सेवा उपयुक्त ठरते.