Thuta Learning
API Integration & Webhooks
BasicWeb Developmentintermediate

SDK vs Raw API

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • SDK vs Raw API concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး request/response (သို့) event flow ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် ကိုယ်ပိုင် API integration အတွက် ဘယ်လို အသုံးချသင့်သလဲ ရှင်းပြနိုင်ရန်

နားလည်ထားရမယ့် အချက်

ဒီ course ထဲက code example တိုင်းလုနီးပါးဟာ `fetch` ကို တိုက်ရိုက်ခေါ်ပြီး header နဲ့ response ကို ကိုယ်တိုင် parse လုပ်ခဲ့ပါတယ်။ ဒါက raw API approach ပါ — control အပြည့်ရှိပြီး dependency အပို မလိုပါဘူး၊ ဒါပေမယ့် auth header, retry logic, pagination, provider ရဲ့ response shape ပြောင်းလဲလာတာကို ကိုယ်တိုင် တာဝန်ယူရပါတယ်။

Provider အများစုက official SDK ကိုလည်း publish လုပ်ကြပါတယ် — raw HTTP call တွေကို typed method name အောက်မှာ wrap လုပ်ပေးထားတဲ့ library တစ်ခုပါ။ Header ကို ကိုယ်တိုင် တည်ဆောက်မယ့်အစား `stripe.charges.create({ amount, currency })` လိုမျိုး ခေါ်လိုက်ရုံနဲ့ SDK က auth, retry, pagination, validation ကို internally ကိုင်တွယ်ပေးပါတယ်။

AspectRaw API vs SDK
ControlRaw API — request/response အားလုံးကို အပြည့်အဝ ထိန်းချုပ်နိုင်တယ်။ SDK — SDK ရဲ့ method design အတိုင်းသာ ကန့်သတ်ထားတယ်။
BoilerplateRaw API — header, parsing, error handling ကို ကိုယ်တိုင် ရေးရတယ်။ SDK — method call တစ်ကြောင်းလောက်နဲ့ ပြီးတတ်တယ်။
DependenciesRaw API — extra dependency မလိုဘူး။ SDK — install, update, trust လုပ်ရမယ့် library အသစ်တစ်ခု။
VersioningRaw API — provider ရဲ့ feature အသစ်ကို ချက်ချင်း သုံးလို့ရတယ်။ SDK — SDK ရဲ့ release cadence နောက်မှ လိုက်ရတတ်တယ်။
Pagination handlingRaw API — page logic ကို ကိုယ်တိုင် implement ရတယ်။ SDK — iterator/helper method တွေက အလိုအလျောက် ကိုင်တွယ်ပေးတတ်တယ်။

ဘယ်ရွေးချယ်မှုမှ universally မှန်ကန်တာ မဟုတ်ပါဘူး။ မှန်ကန်တဲ့ ရွေးချယ်မှုက သင့် language ecosystem၊ specific SDK ဟာ ဘယ်လောက် mature ပြီး ထိန်းသိမ်းမှု ကောင်းလဲ၊ boilerplate ဘယ်လောက်ကို သင့် project က ရေးထိန်းသိမ်းနိုင်လဲဆိုတဲ့ အချက်တွေ အပေါ် မူတည်ပါတယ်။

text
RAW API PATH VS SDK PATH
------------------------
RAW API PATH
------------
  App -> build headers/body -> fetch() -> parse response -> result

SDK PATH
--------
  App -> sdk.charges.create(params) -> [auth+retry+parse inside] -> result

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

`rawApiCharge` က raw path ကို ပြသပါတယ် — pass in လုပ်ထားတဲ့ API key ကနေ `Authorization` header ကို ကိုယ်တိုင် တည်ဆောက်ပြီး JSON body ကို serialize လုပ်ကာ real HTTP response ကို ကိုယ်တိုင် parse လုပ်ရင် ရလာမယ့်အရာကို ကိုယ်စားပြုတဲ့ `parsedResult` ကို ပြန်ပေးပါတယ်။ Plumbing တစ်ခုစီဟာ caller ရဲ့ တာဝန်ပါ။

`sdkCharge` က logical operation တူတူကို SDK တစ်ခုက ဘယ်လို expose လုပ်မလဲဆိုတာကို ပြသပါတယ် — caller က တကယ် အရေးကြီးတဲ့ parameter တွေကိုပဲ pass လုပ်ပြီး `parsedResult` ပုံစံတူတူကို ပြန်ရပါတယ်။ `apiKey` parameter (သို့) header တည်ဆောက်တာ ဘာမှ မမြင်ရပါဘူး။

Function နှစ်ခုစလုံးက logical charge result အတိအကျတူတူကို ထုတ်ပေးပါတယ်။ Output က ပြသနေတဲ့ ကွာခြားချက်ကတော့ caller ရေးရေးထိန်းသိမ်းရမယ့် boilerplate မှာသာ ရှိပါတယ် — raw version မှာ explicit ဖြစ်ပြီး SDK version မှာတော့ ဖျောက်ထားပါတယ်။

အတူတူ စမ်းရေးကြည့်မယ်

javascript
function rawApiCharge(apiKey, amount, currency) {
  const headers = {
    "Authorization": `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  };
  const body = JSON.stringify({ amount, currency });
  return {
    via: "raw",
    headers,
    body: JSON.parse(body),
    parsedResult: { id: "ch_raw_1", amount, currency, status: "succeeded" }
  };
}

function sdkCharge(amount, currency) {
  return {
    via: "sdk",
    parsedResult: { id: "ch_sdk_1", amount, currency, status: "succeeded" }
  };
}

console.log(rawApiCharge("sk_test_123", 2000, "usd"));
console.log(sdkCharge(2000, "usd"));
You should see
raw -> { via: 'raw', headers: { Authorization: 'Bearer sk_test_123', 'Content-Type': 'application/json' }, body: { amount: 2000, currency: 'usd' }, parsedResult: { id: 'ch_raw_1', amount: 2000, currency: 'usd', status: 'succeeded' } }
sdk -> { via: 'sdk', parsedResult: { id: 'ch_sdk_1', amount: 2000, currency: 'usd', status: 'succeeded' } }
(parsedResult ရဲ့ logical shape တူညီပေမယ့် sdk version မှာ header/auth code လုံးဝ မမြင်ရပါ)

၅ မိနစ် စမ်းကြည့်

`rawApiCharge` နဲ့ `sdkCharge` ကို run ကြည့်ပြီး code line အရေအတွက် ရေတွက်ကြည့်ပါ။ Project အသစ်တစ်ခုမှာ pagination ပါတဲ့ provider တစ်ခုကို integrate လုပ်ရမယ်ဆိုရင် raw API (သို့) SDK ဘယ်ဟာ ရွေးမလဲ ဆုံးဖြတ်ပြီး အကြောင်းပြချက် ရေးကြည့်ပါ။

သတိလေးတစ်ချက်

SDK က slower (သို့) worse လို့ blanket statement ချမှတ်ခြင်း — mature SDK အများစုက production-grade retry/auth logic ကို ကောင်းစွာ ကိုင်တွယ်ပေးတယ်

Raw API ကို SDK feature parity ရှိတယ်လို့ ယူဆပြီး provider ရဲ့ documentation ကို မစစ်ဘဲ pagination/retry logic ကို self-implement လုပ်ခြင်း

Stripe API LibrariesAPI Integration & Webhooks

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • SDK က slower (သို့) worse လို့ blanket statement ချမှတ်ခြင်း — mature SDK အများစုက production-grade retry/auth logic ကို ကောင်းစွာ ကိုင်တွယ်ပေးတယ်
  • Raw API ကို SDK feature parity ရှိတယ်လို့ ယူဆပြီး provider ရဲ့ documentation ကို မစစ်ဘဲ pagination/retry logic ကို self-implement လုပ်ခြင်း
  • API Tutorial (apiguide) ကို မလေ့လာရသေးရင် ဒီ course ကို စမလိုက်ခင် အရင် ပြီးအောင် လေ့လာထားသင့်ပါတယ် — ဒီ course က REST/HTTP/Auth အခြေခံတွေကို ထပ်မသင်ဘဲ webhook, testing, reliability, integration architecture တို့ကိုသာ ဆက်လက် တည်ဆောက်ပါတယ်။

လေ့ကျင့်ခန်း

`rawApiCharge` နဲ့ `sdkCharge` ကို run ကြည့်ပြီး code line အရေအတွက် ရေတွက်ကြည့်ပါ။ Project အသစ်တစ်ခုမှာ pagination ပါတဲ့ provider တစ်ခုကို integrate လုပ်ရမယ်ဆိုရင် raw API (သို့) SDK ဘယ်ဟာ ရွေးမလဲ ဆုံးဖြတ်ပြီး အကြောင်းပြချက် ရေးကြည့်ပါ။

You'll know it worked when: raw -> { via: 'raw', headers: { Authorization: 'Bearer sk_test_123', 'Content-Type': 'application/json' }, body: { amount: 2000, currency: 'usd' }, parsedResult: { id: 'ch_raw_1', amount: 2000, currency: 'usd', status: 'succeeded' } } sdk -> { via: 'sdk', parsedResult: { id: 'ch_sdk_1', amount: 2000, currency: 'usd', status: 'succeeded' } } (parsedResult ရဲ့ logical shape တူညီပေမယ့် sdk version မှာ header/auth code လုံးဝ မမြင်ရပါ)