REST API உருவாக்குவது எப்படி: வடிவமைப்பு, பாதுகாப்பு மற்றும் வெளியீடு

REST API உருவாக்க, உங்கள் ஆப் நிர்வகிக்கும் resources (users, orders, bookings) பட்டியலிடுங்கள், ஒவ்வொன்றுக்கும் /orders மற்றும் /orders/{id} போன்ற URL கொடுங்கள், செயல்களுக்கு HTTP methods பயன்படுத்துங்கள்: படிக்க GET, உருவாக்க POST, புதுப்பிக்க PATCH, நீக்க DELETE. அர்த்தமுள்ள status codes-உடன் JSON திருப்பியனுப்புங்கள், ஒவ்வொரு உள்ளீட்டையும் validate செய்யுங்கள், authentication மற்றும் பதிவுக்கு பதிவு அனுமதிச் சோதனையை சர்வரில் வையுங்கள், பட்டியல்களை pagination செய்யுங்கள். பின்னர் endpoints-ஐ ஆவணப்படுத்தி, HTTPS-க்குப் பின்னால் API-ஐ வெளியிடுங்கள்.

இந்த வழிகாட்டி வடிவமைப்பு முடிவுகள், ஒரு செயல்முறை எடுத்துக்காட்டு routes, AI app builder-க்கான prompts, மற்றும் பாதுகாப்பு ஓட்டைகளுக்கு வழிவகுக்கும் தவறுகளை உள்ளடக்கியது. API-கள் உங்களுக்குப் புதியவை என்றால், API என்றால் என்ன என்பதிலிருந்து தொடங்குங்கள்.

REST API எப்போது தேவை

• உங்கள் web frontend-க்கு சர்வரிலிருந்து தரவைச் சேமிக்கவும் ஏற்றவும் வேண்டும்
• மொபைல் ஆப், partner அல்லது automation கருவிக்கு உங்கள் தரவு அணுகல் தேவை
• வேறு சேவைகள் உங்களுக்கு நிகழ்வுகளை அனுப்புகின்றன (webhooks)
• frontend மற்றும் backend குழுக்களுக்கு இடையே வேலையைப் பிரிக்கிறீர்கள்

REST மிகப் பொதுவான பாணி, ஆனால் ஒரே பாணி அல்ல. ஒரு நெகிழ்வான query endpoint எப்போது பொருந்தும் என்பதை REST vs GraphQL விளக்குகிறது.

முதலில் வடிவமைக்கவும்: resources மற்றும் routes

உங்கள் ஆப்பிலுள்ள nouns மற்றும் மக்கள் அவற்றுடன் என்ன செய்கிறார்கள் என்பதை எழுதுங்கள். ஒரு எளிய booking ஆப்புக்கு:

இவை create, read, update, delete ஆகியவற்றுடன் பொருந்துகின்றன; CRUD என்றால் என்ன என்பதைப் பாருங்கள். பின்பற்றத் தகுந்த விதிகள்:

• URL-களில் பன்மை nouns, verbs இல்லை: /getBookings அல்ல, /bookings.
• உரிமையை தெளிவுபடுத்தும்போது ஒரே ஒரு நிலை மட்டும் nest செய்யுங்கள்: /bookings/{id}/notes.
• CRUD அல்லாத செயல்கள் sub-resources ஆக இருக்கலாம்: POST /bookings/{id}/cancel ஒரு மர்ம PATCH-ஐ விட தெளிவானது.
• நிலையான பெயரிடல் fields-க்கு, உதாரணமாக எல்லா இடத்திலும் created_at.

Status codes மற்றும் பிழைகள்

உரையை அலசாமல் கிளையண்ட்கள் என்ன நடந்தது என்று அறிய நிலையான HTTP codes பயன்படுத்துங்கள்:

பிழைகளை ஒரே நிலையான JSON வடிவில் திருப்பியனுப்புங்கள், உதாரணமாக {"error": {"code": "slot_taken", "message": "அந்த நேரம் இனி கிடைக்காது."}}. பதில்களில் ஒருபோதும் stack traces அல்லது database பிழைகளைச் சேர்க்காதீர்கள்.

விருப்பங்கள் மற்றும் சமரசங்கள்

படிப்படியாக

1. மேலே உள்ளபடி resources மற்றும் routes-ஐப் பட்டியலிடுங்கள், ஒவ்வொன்றையும் யார் அழைக்கலாம் என்பதுடன்.
2. உங்களுக்குத் தேவையான fields மற்றும் உறவுகளுடன் உங்கள் database-இல் தரவை மாதிரியாக்குங்கள்.
3. படிக்கும் routes-ஐ முதலில் உருவாக்குங்கள், பின்னர் create, update மற்றும் delete.
4. ஒவ்வொரு write-லும் ஒரு schema library மூலம் உள்ளீட்டை validate செய்யுங்கள்: தேவையான fields, வகைகள், நீளங்கள், அனுமதிக்கப்பட்ட மதிப்புகள். தெரியாத fields-ஐ நிராகரியுங்கள்.
5. Authentication சேர்க்கவும், பின்னர் பதிவுக்கு பதிவு authorisation: /bookings/42-ஐ ஏற்றும்போது booking 42 அழைப்பவருக்குச் சொந்தமா என்று சரிபார்க்க வேண்டும், யாரோ உள்நுழைந்துள்ளார் என்பது மட்டும் போதாது.
6. ஒவ்வொரு பட்டியலையும் paginate செய்து page அளவை வரம்பிடுங்கள்.
7. login மற்றும் செலவு மிகுந்த routes-க்கு rate-limit வையுங்கள். rate limiting என்றால் என்ன பாருங்கள்.
8. வெளி domains-இல் உள்ள browsers API-ஐ அழைக்க வேண்டுமானால் மட்டும் CORS அமையுங்கள், அந்த origins-ஐ வெளிப்படையாகப் பட்டியலிடுங்கள். நீங்கள் காணும் பிழைகளை CORS பிழைகளை எப்படி சரிசெய்வது விளக்குகிறது.
9. ஒவ்வொரு route-க்கும் ஆவணங்களும் சோதனைகளும் எழுதுங்கள், தோல்வி நிகழ்வுகளையும் சேர்த்து.
10. ரகசியங்களை environment variables-இல் வைத்து, HTTPS, logs மற்றும் health check உடன் deploy செய்யுங்கள்.

உங்கள் AI builder-க்குக் கொடுக்க வேண்டிய prompts

Scaffold:

bookings-க்கான REST API ஒன்றை இந்த routes-உடன் உருவாக்கவும்: GET /api/health, GET /api/bookings (paginated, ஒரு page-க்கு அதிகபட்சம் 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. எங்கள் database-இல் தரவைச் சேமிக்கவும். Request bodies-ஐ ஒரு schema library மூலம் validate செய்து, தெரியாத fields-ஐ நிராகரிக்கவும். பிழைகளை {"error": {"code", "message"}} வடிவில் சரியான status codes-உடன் (400, 401, 403, 404, 409) JSON-ஆகத் திருப்பவும். ரகசியங்களை environment variables-இல் வைக்கவும்.

பாதுகாப்பு:

ஒவ்வொரு bookings route-க்கும் உள்நுழைவு கேளுங்கள். ஒவ்வொரு read, update மற்றும் delete-லும் அந்த booking தற்போதைய பயனருக்குச் சொந்தமா என்று சர்வரில் சரிபார்க்கவும்; இல்லையென்றால் 404 திருப்பவும். request body-இலிருந்து user IDs அல்லது roles-ஐ ஒருபோதும் ஏற்காதீர்கள். POST /api/bookings-ஐ பயனருக்கு நிமிடத்திற்கு 20 என rate-limit செய்யுங்கள். சர்வரில் பிழைகளைப் பதிவு செய்யுங்கள், stack traces-ஐ திருப்பி அனுப்பாதீர்கள்.

ஆவணங்கள்:

இந்த routes-இன் OpenAPI விளக்கத்தையும், ஒவ்வொன்றுக்கும் எடுத்துக்காட்டு requests மற்றும் responses உடன் ஒரு சிறிய README-ஐயும் எழுதவும்.

உங்கள் API-ஐ சோதித்தல்

Frontend-க்கு வெளியிலிருந்து சோதியுங்கள், ஏனெனில் தாக்குபவர்கள் அப்படித்தான் சோதிப்பார்கள்:

• ஒவ்வொரு route-உம் சரியான உள்ளீட்டுடன் வேலை செய்து, ஆவணப்படுத்திய வடிவம் மற்றும் code-ஐத் திருப்புகிறது
• காணாமல் போன அல்லது தவறான fields 400 மற்றும் தெளிவான செய்தியுடன் திரும்புகின்றன
• பாதுகாக்கப்பட்ட ஒவ்வொரு route-லும் token இல்லாவிட்டால் 401
• பயனர் A, ID மூலம் பயனர் B-யின் பதிவைக் கேட்டால் 404 அல்லது 403
• பட்டியல்கள் paginate ஆகின்றன; மிகப் பெரிய limit வரம்பிடப்படுகிறது
• நகல் அல்லது முரண்படும் creates 500 அல்ல, 409 திருப்புகின்றன
• rate limits 429 திருப்புகின்றன
• பிழை பதில்களில் stack traces, SQL அல்லது ரகசியங்கள் இல்லை
• CORS நீங்கள் நோக்கிய origins-ஐ மட்டுமே அனுமதிக்கிறது

பொதுவான தவறுகள்

• உள்நுழைவைச் சரிபார்த்து உரிமையைச் சரிபார்க்காதது. மிகப் பொதுவான API ஓட்டை: எந்த உள்நுழைந்த பயனரும் ID-ஐ மாற்றி எந்தப் பதிவையும் படிக்கலாம்.
• கிளையண்டை நம்புவது. request body-இலிருந்து வரும் விலைகள், roles மற்றும் user IDs திருத்தப்படலாம்.
• முழு database வரிசைகளைத் திருப்புவது. கடவுச்சொல் hashes மற்றும் உள் fields கசியும். ஒவ்வொரு பதிலிலும் எது இருக்க வேண்டும் என்று தேர்ந்தெடுங்கள்.
• எல்லையற்ற பட்டியல்கள். ஒவ்வொரு பதிவுக்கும் ஒரே கோரிக்கை முழு ஆப்பையும் மெதுவாக்கலாம்.
• உள்ளே பிழைச் செய்தியுடன் 200 OK. கிளையண்ட்களும் monitoring-உம் தோல்வியை அறிய முடியாது.
• cookies பயன்படுத்தும் API-இல் எல்லாவற்றையும் அனுமதிக்கும் CORS.
• health check அல்லது logs இல்லாதது, அதனால் பயனர்களிடமிருந்தே outage-ஐ அறிவீர்கள்.

பரந்த வெளியீட்டுக்கு முந்தைய சரிபார்ப்புக்கு, AI-ஆல் கட்டப்பட்ட ஆப்புகளுக்கான பாதுகாப்புப் பட்டியல் பாருங்கள்.

Mythex-இல் REST API உருவாக்குதல்

உங்கள் ஆப்பின் ஒரு பகுதியாகவோ அல்லது தனி சேவையாகவோ Mythex-இடம் API கேட்கலாம். ஆவணங்களின் REST API backend recipe-இல் ஒரு தொடக்க prompt உள்ளது: உங்கள் framework மற்றும் routes-ஐ பெயரிடுங்கள், தெளிவான JSON பிழைகளைக் கேளுங்கள், ரகசியங்களை environment variables-இல் வைத்திருங்கள், Dockerfile சேர்க்கவும். Node, Python, C#, Java மற்றும் பிற மொழிகளின் container backends Dockerfile மூலம் வெளியிடப்படுகின்றன; Publish-இலிருந்து deploy-ஐ Mythex கையாளும் (API backends). ஒரு project web தளத்தையும் API சர்வரையும் அருகருகே இயக்கலாம், preview-இல் இரண்டுக்கும் இடையே மாறலாம். ரகசியங்களை project secrets-ஆகச் சேமியுங்கள்; API-க்கு database தேவைப்பட்டால் chat-இல் கேளுங்கள். உங்கள் API-ஐச் சுற்றியுள்ள திட்டமிட்ட வேலைகளுக்கு, background jobs இயக்குவது எப்படி பாருங்கள்.

கேள்விகள்