REST API တည်ဆောက်နည်း: Design၊ Security နှင့် Deployment

REST API တည်ဆောက်ရန် သင့်အက်ပ်စီမံသော resource များ (users၊ orders၊ bookings) ကို စာရင်းပြုစုပါ၊ တစ်ခုစီကို /orders နှင့် /orders/{id} ကဲ့သို့ URL ပေးပါ၊ လုပ်ဆောင်ချက်များအတွက် HTTP method များကို သုံးပါ- ဖတ်ရန် GET၊ ဖန်တီးရန် POST၊ ပြင်ဆင်ရန် PATCH၊ ဖျက်ရန် DELETE။ အဓိပ္ပာယ်ရှိသော status code များပါသည့် JSON ကို ပြန်ပို့ပါ၊ input တိုင်းကို validate လုပ်ပါ၊ authentication နှင့် record တစ်ခုချင်းစီအတွက် ခွင့်ပြုချက် စစ်ဆေးမှုကို server ပေါ်တွင် တောင်းဆိုပါ၊ စာရင်းများကို paginate လုပ်ပါ။ ထို့နောက် endpoint များကို document ပြုစုပြီး API ကို HTTPS နောက်တွင် deploy လုပ်ပါ။

ဤလမ်းညွှန်တွင် design ဆုံးဖြတ်ချက်များ၊ လက်တွေ့ route အစုံ၊ AI app builder အတွက် prompt များနှင့် လုံခြုံရေးအပေါက်ဖြစ်စေသော အမှားများကို ဖော်ပြထားသည်။ API အသစ်ဖြစ်ပါက API ဆိုတာ ဘာလဲ ဖြင့် စတင်ပါ။

REST API လိုအပ်သည့်အခါ

• သင့် web frontend က server မှ data သိမ်းရန်နှင့် ဖတ်ရန် လိုအပ်သောအခါ
• Mobile app၊ partner သို့မဟုတ် automation tool က သင့် data ကို ဝင်ရောက်ရန် လိုအပ်သောအခါ
• အခြား service များက သင့်ထံ event များ ပို့သောအခါ (webhooks)
• Frontend နှင့် backend အဖွဲ့များကြား အလုပ်ကို ခွဲဝေသောအခါ

REST သည် အသုံးအများဆုံး style ဖြစ်သော်လည်း တစ်ခုတည်း မဟုတ်ပါ။ REST နှင့် GraphQL က ပြောင်းလွယ်သော query endpoint တစ်ခုတည်းက ဘယ်အချိန် ပိုသင့်လျော်သလဲဆိုသည်ကို ရှင်းပြသည်။

အရင်ဆုံး design: resource နှင့် route များ

သင့်အက်ပ်ရှိ nouns များနှင့် လူများက ၎င်းတို့ဖြင့် ဘာလုပ်သလဲကို ရေးချပါ။ ရိုးရှင်းသော booking app အတွက်-

ဤများသည် create၊ read၊ update နှင့် delete တို့နှင့် ကိုက်ညီသည်။ ကြည့်ရန် CRUD ဆိုတာ ဘာလဲ။ လိုက်နာရန် ကောင်းသော စည်းကမ်းများ-

• URL များတွင် နာမ်စားအသုံး (plural noun)၊ ကြိယာမသုံး: /getBookings မဟုတ် /bookings။
• ပိုင်ဆိုင်မှုကို ရှင်းလင်းစေရန်လိုသည့်အခါ အဆင့်တစ်ဆင့်တည်းသာ nest လုပ်: /bookings/{id}/notes။
• CRUD မဟုတ်သော လုပ်ဆောင်ချက်များကို sub-resource အဖြစ် ထားနိုင်သည်- POST /bookings/{id}/cancel သည် magic PATCH ထက် ပိုရှင်းလင်းသည်။
• Field အမည်များကို တသမတ်တည်း ပေးပါ၊ ဥပမာ created_at ကို နေရာတိုင်းတွင် သုံးပါ။

Status code နှင့် error များ

Client များသည် စာသားကို parse မလုပ်ဘဲ ဘာဖြစ်သွားသလဲ သိနိုင်ရန် HTTP code စံများကို သုံးပါ-

Error များကို JSON ပုံစံ တစ်မျိုးတည်းဖြင့် ပြန်ပို့ပါ၊ ဥပမာ {"error": {"code": "slot_taken", "message": "ထိုအချိန် မရနိုင်တော့ပါ။"}}၊ နှင့် တုံ့ပြန်မှုများတွင် stack trace သို့မဟုတ် database error များကို ဘယ်တော့မှ မထည့်ပါနှင့်။

Option များနှင့် trade-off များ

အဆင့်လိုက် လုပ်ဆောင်ချက်

1. အထက်ပါအတိုင်း resource နှင့် route များကို စာရင်းပြုစု၊ တစ်ခုစီကို ဘယ်သူခေါ်နိုင်သလဲ ပါ။
2. လိုအပ်သော field များနှင့် ဆက်စပ်မှုများဖြင့် data ကို ပုံဖော် သင့် database တွင်။
3. ဖတ်သော route များကို အရင်တည်ဆောက်၊ ထို့နောက် create၊ update နှင့် delete။
4. Write တိုင်းတွင် input ကို validate လုပ်၊ schema library ဖြင့်- လိုအပ်သော field၊ type၊ အရှည်၊ ခွင့်ပြုထားသော တန်ဖိုးများ။ မသိသော field များကို ပယ်ချပါ။
5. Authentication ထည့်၊ ထို့နောက် record တစ်ခုချင်းစီအတွက် authorisation- /bookings/42 ကို ဖတ်ရာတွင် တစ်စုံတစ်ယောက် login ဝင်ထားသည်ထက် booking 42 သည် ခေါ်ဆိုသူ၏ဖြစ်မဖြစ် စစ်ဆေးရမည်။
6. စာရင်းတိုင်းကို paginate လုပ် နှင့် page size ကို ကန့်သတ်ပါ။
7. Login နှင့် ကုန်ကျစရိတ်များသော route များကို rate-limit လုပ်ပါ။ Rate limiting ကို ကြည့်ပါ။
8. Browser များက အခြား domain မှ API ကို ခေါ်ရန် လိုအပ်မှသာ CORS ကို configure လုပ်ပြီး ထို origin များကို ရှင်းရှင်းလင်းလင်း စာရင်းပြုစုပါ။ CORS error များကို ဖြေရှင်းနည်း တွင် တွေ့ရမည့် error များကို ရှင်းပြထားသည်။
9. Route တစ်ခုစီအတွက် docs နှင့် test များ ရေးပါ၊ failure case များအပါအဝင်။
10. Secret များကို environment variable၊ HTTPS၊ log နှင့် health check ပါသော deploy လုပ်ပါ။

AI builder အတွက် prompt များ

Scaffold:

Bookings အတွက် REST API ဖန်တီးပါ၊ route များမှာ- GET /api/health၊ GET /api/bookings (paginated၊ page တစ်ခုလျှင် အများဆုံး 50)၊ POST /api/bookings၊ GET /api/bookings/:id၊ PATCH /api/bookings/:id၊ DELETE /api/bookings/:id။ Data ကို ကျွန်ုပ်တို့ database တွင် သိမ်းပါ။ Request body များကို schema library ဖြင့် validate လုပ်ပြီး မသိသော field များကို ပယ်ပါ။ JSON error များကို {"error": {"code", "message"}} ပုံစံဖြင့် မှန်ကန်သော status code များ (400၊ 401၊ 403၊ 404၊ 409) ဖြင့် ပြန်ပို့ပါ။ Secret များကို environment variable တွင် ထားပါ။

Security:

Bookings route အားလုံးအတွက် login ဝင်ရန် တောင်းဆိုပါ။ Read၊ update နှင့် delete တိုင်းတွင် booking သည် လက်ရှိအသုံးပြုသူ၏ ဖြစ်မဖြစ် server ပေါ်တွင် စစ်ဆေးပါ၊ မဟုတ်ပါက 404 ပြန်ပို့ပါ။ Request body မှ user ID သို့မဟုတ် role ကို ဘယ်တော့မှ လက်မခံပါနှင့်။ POST /api/bookings ကို အသုံးပြုသူတစ်ဦးလျှင် မိနစ်လျှင် 20 ကြိမ်အထိ rate-limit လုပ်ပါ။ Server ပေါ်တွင် error များကို log ပြုပါ၊ stack trace မပြန်ပို့ပါနှင့်။

Docs:

ဤ route များအတွက် OpenAPI description နှင့် route တစ်ခုစီအတွက် example request နှင့် response ပါသော အတိုလေး README တစ်ခု ရေးပါ။

API ကို test လုပ်ခြင်း

တိုက်ခိုက်သူများ လုပ်မည့်အတိုင်း frontend အပြင်မှ test လုပ်ပါ-

• Route တစ်ခုစီသည် မှန်ကန်သော input ဖြင့် အလုပ်လုပ်ပြီး document လုပ်ထားသော shape နှင့် code ကို ပြန်ပို့သည်
• လိုအပ်သော သို့မဟုတ် မမှန်သော field များသည် ရှင်းလင်းသော message ပါ 400 ကို ပြန်ပို့သည်
• Token မပါဘဲ ကာကွယ်ထားသော route တိုင်းတွင် 401 ပြန်ပို့သည်
• အသုံးပြုသူ A က အသုံးပြုသူ B ၏ record ကို ID ဖြင့် တောင်းလျှင် 404 သို့မဟုတ် 403 ရသည်
• စာရင်းများကို paginate လုပ်ထားပြီး အလွန်ကြီးသော limit ကို ကန့်သတ်ထားသည်
• ထပ်နေသော သို့မဟုတ် ဆန့်ကျင်နေသော create များသည် 500 မဟုတ်ဘဲ 409 ပြန်ပို့သည်
• Rate limit များက 429 ပြန်ပို့သည်
• Error တုံ့ပြန်မှုများတွင် stack trace၊ SQL သို့မဟုတ် secret မပါ
• CORS က ရည်ရွယ်ထားသော origin များကိုသာ ခွင့်ပြုသည်

အဖြစ်များသော အမှားများ

• Login ကို စစ်ပြီး ပိုင်ဆိုင်မှုကို မစစ်ခြင်း။ အသုံးများဆုံး API အပေါက်ဖြစ်သည်- logged-in အသုံးပြုသူ မည်သူမဆို ID ပြောင်းခြင်းဖြင့် မည်သည့် record ကိုမဆို ဖတ်နိုင်သည်။
• Client ကို ယုံခြင်း။ Request body မှ စျေးနှုန်း၊ role နှင့် user ID များကို တည်းဖြတ်နိုင်သည်။
• Database row တစ်ခုလုံးကို ပြန်ပို့ခြင်း။ Password hash နှင့် internal field များ ယိုဖိတ်သည်။ Response တစ်ခုစီတွင် ဘာပါမည်ကို ရွေးပါ။
• ကန့်သတ်မထားသော စာရင်းများ။ Record အားလုံးအတွက် request တစ်ခုက app တစ်ခုလုံးကို နှေးစေနိုင်သည်။
• Error message ပါသော 200 OK။ Client နှင့် monitoring တို့က ပျက်ကွက်ကြောင်း မသိနိုင်ပါ။
• Cookie သုံးသော API တွင် အားလုံးကို ခွင့်ပြုရန် CORS သတ်မှတ်ခြင်း။
• Health check သို့မဟုတ် log မရှိခြင်း၊ ထို့ကြောင့် ပြတ်တောက်မှုကို အသုံးပြုသူများထံမှ သိရသည်။

ပြင်ပသို့ မထုတ်မီ ပိုကျယ်သော စစ်ဆေးမှုအတွက် AI-built app များအတွက် security checklist ကို ကြည့်ပါ။

Mythex တွင် REST API တည်ဆောက်ခြင်း

သင့်အက်ပ်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် သို့မဟုတ် ကိုယ်ပိုင် service အဖြစ် Mythex ကို API တောင်းနိုင်သည်။ Docs recipe REST API backend တွင် starter prompt ရှိသည်- framework နှင့် route များကို အမည်ပေးပါ၊ ရှင်းလင်းသော JSON error များကို တောင်းပါ၊ secret များကို environment variable တွင် ထားပါ၊ Dockerfile ထည့်ပါ။ Node၊ Python၊ C#၊ Java နှင့် အခြားသော container backend များကို Dockerfile ဖြင့် publish လုပ်ပြီး Mythex က Publish မှ deploy ကို ကိုင်တွယ်ပေးသည် (API backends)။ Project တစ်ခုတွင် website နှင့် API server ကို ဘေးတိုက်ထားနိုင်ပြီး preview တွင် ပြောင်းကြည့်နိုင်သည်။ Secret များကို project secret အဖြစ် သိမ်းပါ၊ API ကို database လိုအပ်ပါက chat တွင် တောင်းပါ။ API အတွက် scheduled အလုပ်များအတွက် background job များ ဖွင့်နည်း ကို ကြည့်ပါ။

မေးခွန်းများ