Mon May 26 2025 • 8 mins read
API နည်းပညာဟာ မော်ဒန် Web Development ရဲ့ အဓိကအခန်းကဏ္ဍမှာ ရှိနေပါတယ်။ Application တွေရဲ့ Frontend နဲ့ Backend အချင်းချင်း ဆက်သွယ်ဖို့အတွက် API တွေကို အသုံးပြုရပါတယ်။ အခြေခံ Application တွေကစပြီး နောက်ပိုင်းမှာ ရှုပ်ထွေးတဲ့ Application Design တွေအဖြစ် တိုးတက်ပြောင်းလဲလာတာနဲ့အမျှ API တွေရဲ့ လုပ်ဆောင်မှုတွေဟာလည်း ပိုမိုအားကောင်းလာပါတယ်။
၂၀၀၀ ခုနှစ်မှာ Roy Fielding က REST (Representational State Transfer) ဆိုတဲ့ နည်းပညာကို မိတ်ဆက်ပေးခဲ့တဲ့အချိန်ကစပြီး Web API Design ရဲ့ Standard တစ်ခုအဖြစ် အသုံးပြုလာခဲ့ကြပါတယ်။ REST ဟာ Resource အသီးသီးကို URL တွေ (တနည်းအားဖြင့် Endpoint တွေ) နဲ့ ကိုယ်စားပြုပါတယ်။ CRUD လုပ်ဆောင်ချက်အဖြစ် မတူညီတဲ့ HTTP Method တွေ (GET,POST, PUT, DELETE စသည်ဖြင့်) ကို အသုံးပြုပြီး Resource တွေကို ပြုပြင်ထိန်းသိမ်းနိုင်ပါတယ်။ Endpoint တခုစီတိုင်းဟာ တောင်းဆိုလိုက်တဲ့ ဒေတာတွေကို ပုံသေ Fixed Structure အတိုင်းသာ ပြန်ပို့ပေးမှာဖြစ်ပါတယ်။ ဥပမာ၊ User ဒေတာကို ရယူဖို့အတွက်ဆိုရင် GET /users/:id ဆိုတဲ့ Endpoint ကို အသုံးပြုရမှာဖြစ်ပြီး အဆိုပါ User ရဲ့ Post ဒေတာတွေကို ရယူလိုရင်တော့ GET /users/:id/posts ဆိုပြီး ခေါ်ယူသုံးစွဲရမှာဖြစ်ပါတယ်။
၂၀၁၂ ခုနှစ်မှာ ဖေ့စ်ဘုတ်က GraphQL ကို မိတ်ဆက်ပေးလာခဲ့ပါတယ်။ သမရိုးကျ REST API နည်းပညာအစား အသုံးပြုနိုင်မယ့် API Query Language အဖြစ် လူသိများပါတယ်။ REST ဟာ ဆယ်စုနှစ်နီးပါး API စံတခုအဖြစ်ရှိခဲ့ပေမယ့်လည်း GraphQL ကတော့ မတူညီတဲ့ ရှုထောင့်ကနေ ဒေတာတွေကို ဘယ်လိုမျိုးခေါ်ယူသုံးစွဲနိုင်မလဲဆိုတဲ့အပေါ် အခြေခံထားတဲ့အတွက် လူကြိုက်များလာခဲ့ပါတယ်။
GraphQL ဟာ Endpoint တခုတည်းကိုသာ အသုံးပြုပြီး ဒေတာတွေကို ရယူနိုင်မှာပါ။ အဲဒီအပြင် အဆိုပါ Response ဒေတာတွေရဲ့ Structure ကိုလည်း လိုအပ်သလို ပြင်ဆင်ရယူနိုင်မှာပါ။ GraphQL ဟာ တိတိကျကျ သတ်မှတ်ထားတဲ့ Structure နဲ့ Client ကလိုအပ်တဲ့ ဒေတာအတိုင်းပဲ Response ပြန်ပေးနိုင်တဲ့အတွက် တကယ်တမ်းလိုအပ်တဲ့ ဒေတာ Field တွေကိုသာ သီးခြားကွက်ပြီး ရယူနိုင်မှာပဲဖြစ်ပါတယ်။ ဥပမာ၊ REST မှာလိုမျိုး Endpoint များစွာကို ခေါ်ယူနေဖို့မလိုတော့ဘဲ /graphql ဆိုတဲ့ Endpoint တခုတည်းကနေ လိုအပ်သလို ဒေတာတွေကို ရယူနိုင်မှာပဲဖြစ်ပါတယ်။
GraphQL ရဲ့ အားသာချက်တွေကိုပြောရရင် Flexible Data Fetching နဲ့ Single Query, Multiple Resources လုပ်ဆောင်ချက်တွေကို အသားပေးပြောရမှာဖြစ်ပါတယ်။ တခြားသော API versioning, Error Handling နဲ့ Subscription လုပ်ဆောင်ချက်တွေလည်း ရှိပါသေးတယ်။
Flexible Data Fetching
REST ကို အသုံးပြုတဲ့အခါ Over-Fetching နဲ့ Under-Fetching ပြဿနာဟာ တွေ့ကြုံနေကျဖြစ်ပါတယ်။
ဆိုပါစို့ ကျနော်တို့ဟာ User ရဲ့ name နဲ့ profile ကိုသာ ရယူလိုပေမယ့် တကယ်လိုအပ်တဲ့ ဒေတာ Field တွေအပြင် email, address စသည်ဖြင့် မလိုအပ်တဲ့ ဒေတာ Field တွေပါ ရရှိလာမှာပါ။ ဒါဟာ Over-Fetching သဘောတရားဖြစ်ပါတယ်။ အကယ်၍ လိုအပ်တဲ့ဒေတာတွေ မလုံလောက်သေးတဲ့အခါမှာလည်း တခြားသော Related Information တွေကို ရယူဖို့ အခြား Endpoint တွေကို ထပ်ခေါ်ယူရမှာဦးမှာဖြစ်ပါတယ်။
GraphQL ဟာ Client လိုအပ်တဲ့ ဒေတာ Field တွေကိုသာ တိတိကျကျ Response ပြန်ပေးနိုင်ပါတယ်။ ဒါဟာ Over-Fetching နဲ့ Under-Fetching ပြဿနာတွေကို ဖြေရှင်းပေးပြီး Network Call အကြိမ်အရေအတွက်ကိုလည်း လျှော့ချပေးနိုင်မှာဖြစ်ပါတယ်။
Single Query, Multiple Resources
GraphQL ဟာ Request တခုတည်းမှာ Resource အများအပြားကို ထည့်သွင်းရယူနိုင်ပါတယ်။ ဥပမာ REST မှာဆိုရင် အခြားသက်ဆိုင်ရာ ဒေတာတွေကို ရယူလိုတဲ့အခါ မတူညီတဲ့ Endpoint တွေဆီကို Request တွေ သီးခြားပေးပို့ တောင်းဆိုရမှာဖြစ်ပါတယ်။ /users/:id နဲ့ /users/:id/posts စသည်ဖြင့်ပါ။ GraphQL မှာတော့ Single Query တခုထဲနဲ့ Related Resource (User Info + Posts) တွေကို တခါတည်းနဲ့ ရယူပေးနိုင်မှာဖြစ်ပါတယ်။
နမူနာအနေနဲ့ User နဲ့အတူ သက်ဆိုင်ရာ Post တွေပါဝင်တဲ့ GraphQL Query တခုကို REST နဲ့ နိူင်းယှဉ်ကြည့်ပါ။
REST ~
GET /users/:id
GET /users/:id/posts
GraphQL ~
{
user(id: 1) {
name
profilePicture
posts {
title
createdAt
}
}
}
API versioning
REST မှာဆိုရင် Application ကြီးလာတာနဲ့အမျှ API ကို Version တွေ သတ်မှတ်ပေးဖို့ လိုအပ်လာမှာပါ။ /v1/users, /v2/users စသည်ဖြင့်ပါ။ GraphQL မှာဆိုရင် Version သတ်မှတ်ပေးဖို့ မလိုအပ်ပါဘူး။ ဒေတာ Field တွေကို လိုအပ်သလို Deprecated လုပ်လို့ရပါတယ်။ ဒါဟာ API ပြုပြင်ပြောင်းလဲမှုတွေအတွက် တော်တော်လေး အရေးပါတဲ့ ကဏ္ဍတခုဖြစ်ပါတယ်။
Error Handling
REST မှာဆိုရင် Success/Failure ကို ဖော်ပြဖို့ မတူညီတဲ့ Status Code တွေကို သုံးပါတယ်။ 404 Not Found, 500 Internal Server Error စသည်ဖြင့်ပါ။ ဒီ Error တွေကို ကိုင်တွယ်ရတာကလည်း အနည်းငယ် စိတ်ရှုပ်စရာကောင်းပါတယ်။
GraphQL မှာဆိုရင် Error Handling ကို Response Object ထဲမှာ တိုက်ရိုက်ထည့်သွင်းထားပြီး Standardized လုပ်ထားပါတယ်။ တောင်းဆိုလိုက်တဲ့ Query ရဲ့ တချို့အပိုင်းက Fail ဖြစ်သွားခဲ့ရင်တောင် ရှင်းလင်းတဲ့ Error Message တွေနဲ့အတူ တချို့တဝက်သောဒေတာတွေကို ရရှိနိုင်ဦးမှာဖြစ်ပါတယ်။ ဒါဟာ API Failure တွေကို ပိုပြီးအဆင်ပြေပြေ ကိုင်တွယ်နိုင်စေတာဖြစ်ပါတယ်။
Real-time Data with Subscriptions
REST ဟာ request-response ပေါ်မှာ အခြေခံပါတယ်။ WebSockets ဒါမှမဟုတ် Polling နည်းပညာတွေအသုံးပြုပြီး Real-time Functionality ကို Implement လုပ်နိုင်သလို၊ GraphQL ဟာလည်း Subscription တွေကိုသုံးပြီး Real-Time Update တွေကို Support ပေးထားပါတယ်။ ဒါဟာ Live update လိုအပ်တဲ့ Application တွေ (တနည်းအားဖြင့် Social Media Feeds လိုမျိုးတွေ၊ Collaborative Tool လိုမျိုးတွေ) အတွက် တော်တော်လေး အဆင်ပြေစေတာဖြစ်ပါတယ်။
- ရိုးရှင်းတဲ့ CRUD Operation တွေအတွက် အသုံးပြုသင့်ပါတယ်။
- HTTP header ကိုသုံးပြီး Caching Mechanism ကို လွယ်ကူစွာ ကိုင်တွယ်လိုတဲ့အခါ အသုံးပြုသင့်ပါတယ်။
- Resource-Centric API Design တနည်းအားဖြင့် Resource တွေကို Application အတွက်သာ အလေးပေး အသုံးပြုလိုတဲ့အခါ အသုံးပြုသင့်ပါတယ်။
- ဒေတာတွေကို Fetch လုပ်တဲ့အခါ ပိုပြီး Flexibility ဖြစ်လိုတဲ့အခါ အသုံးပြုသင့်ပါတယ်။
- တကယ်လိုအပ်တဲ့ Field တွေကိုသာ ရယူပြီး Over-fetching နဲ့ Under-fetching ကို လျှော့ချချင်တဲ့အခါ အသုံးပြုသင့်ပါတယ်။
- Application အတွက် Real-Time Data Update တွေ လိုအပ်တဲ့အခါ အသုံးပြုသင့်ပါတယ်။
REST ဟာ Resource-Based Architecture တွေအတွက် သင့်တော်ပြီး ရိုးရှင်းတဲ့ API Pattern တွေအတွက် ရွေးချယ်သင့်ပါတယ်။ GraphQL ဟာ Data-Driven Application တွေအတွက် သင့်တော်ပြီး တိကျတဲ့ဒေတာရလာဒ် တနည်းအားဖြင့် Predictable ဒေတာရလာဒ်တွေအတွက် ရွေးချယ်သင့်ပါတယ်။ တချို့သော Application Architecture တွေမှာတော့ REST နဲ့ GraphQL နည်းပညာ နှစ်ခုလုံးကို အမျိုးမျိုးပေါင်းစပ်အသုံးပြုတတ်ကြပါတယ်။ REST ဟာ ရိုးရှင်းတာကြောင့် ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုသလို၊ Application တွေက ပိုပြီး Complex ဖြစ်လာတာနဲ့အမျှ Efficiency, Scalability နဲ့ Flexibility စသည်ဖြင့် ထည့်သွင်းစဉ်းစားလာရတဲ့အခါ GraphQL ကို ရွေးချယ်လေ့ရှိကြပါတယ်။
#CodewithThura #GraphQL