HTTP နဲ့ REST API နှစ်ခုက မတူပါဘူး

HTTP နဲ့ REST API နှစ်ခုက မတူပါဘူး။ ဘယ်လိုကွာလဲ သိရအောင် HTTP ရဲ့အခြေခံနဲ့ REST principle တွေကို ပြောကြတာပေါ့။ Web developer လုပ်ဖို့ တွေးထားရင် ဒါတွေက သိကိုသိထားရမယ့်ဟာတွေ ဖြစ်တယ်။

HTTP က application protocol ပါ။ ဆိုလိုတာက application နှစ်ခုကြား အပြန်အလှန် ဆက်သွယ်ပြီး ဒေတာ ပေးပို့တဲ့အခါ နှစ်ဖက်လုံးက နားလည်နိုင်အောင် ဒေတာကို ဘယ်လိုတည်ဆောက်မလဲလို့ ကြိုသဘောတူထားတဲ့ ပုံစံတခုဖြစ်တယ်။

GET /index.html HTTP/1.1

Host: google.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Accept-Encoding: gzip, deflate, br

အပေါ်က စာသားကို ဖတ်ကြည့်ပါ။ ဒါက HTTP request တခုပါပဲ။ ဒီ request မှာ ဘယ်သူက၊ ဘယ်နေရာကို၊ ဘာလိုချင်တယ်နဲ့ ဘယ်လိုပုံစံ အကြောင်းပြန်ပေးဖို့ မျှော်လင့်တယ်ဆိုတဲ့ အချက်အလက်တွေကို text အနေနဲ့ အကုန်ရေးထားတာ တွေ့ရမယ်။ တကယ်လို့ payload ပါပါလို့ payload ကို Base64 နဲ့ဖြစ်ဖြစ်၊ တခြားတခုခုနဲ့ဖြစ်ဖြစ် encode လုပ်ချင်တယ်ဆိုရင် အဲဒါကိုလည်း header ထဲမှာ ထည့်ပြောရမယ်။ ဒါမှ လက်ခံရတဲ့ application ဖက်ကဒါကို ဘယ်လို decode ပြန်လုပ်ရမယ်မှန်း သိမယ်။

HTTP နဲ့အတူ ဆက်စပ်ပြီး client နဲ့ server ​လို့ ပြောကြတဲ့ request response model ကိုပါ သိထားရမယ်။ data ရိုးရိုးပို့တယ်ဆိုရင် ကိုယ်ပို့တာ ရောက်ပါတယ်လို့ ပြန်ပြောရဲ့လား။ data တောင်းတယ်ဆိုရင်လည်း ကိုယ်တောင်းတဲ့ data တဖက်က ပြန်ပို့လားပေါ့။ HTTP မှာအသွားနဲ့အပြန် နှစ်ခုပေါင်းကိုမှ တစုံလို့ သတ်မှတ်တယ်။ one cycle ပေါ့။

တဖက်မှာ REST API ဆိုတာကကျ REST principle တွေသုံးပြီး API ရေးတာကို ခေါ်တယ်။ REST ဖြစ်ဖို့အတွက် HTTP သုံးရမယ် မဟုတ်ဘူး။ ဒါပေမယ့် RESTful API အများစုကို HTTP နဲ့ json သုံးပြီး တည်ဆောက်ကြတဲ့အတွက် json-over-http လို့ပြောရင် REST API ကိုပြောတာမှန်း နားလည်နေကြပြီ။

အဓိကကျတဲ့ REST principle ၆ ခုရှိတယ်။

1) နံပါတ်တစ်က client နဲ့ server ကို တာဝန်ကွဲပြားအောင်ထားဖို့ ပြောတာ။

ဒီအချက်က React App နဲ့ Flask App ဆိုပြီး frontend နဲ့ backend ခွဲရေး API ကတဆင့် ဆက်သွယ်ကြလို့ ပြောတာမဟုတ်ဘူး။ application နှစ်ခုမှာ client ကပဲ server ကိုဆက်သွယ်ခိုင်းတာဖြစ်တယ်။ HTTP စကားနဲ့ ပြောမယ်ဆို client ကပဲ request လုပ်ပြီး server ရဲ့တာဝန်ကတော့ response ပြန်ဖို့ဖြစ်သွားတယ်။ ပြောင်းပြန်လုပ်ချင်ရင် ရအောင်လုပ်လို့ ရပါတယ်။ ဒါပေမယ့် မလုပ်ဖို့ သဘောတူထားတယ်။ နောက် client ဆီ business logic တွေ၊ data logic တွေထည့်မပေးလိုက်ရဘူး။ server ကိုပြန်ဆက်သွယ်နိုင်ဖို့ လုံလောက်ရုံ information ကိုပဲပေးရမယ်။ server ဆီမှာလည်း client ရဲ့ UI state တွေ ဥပမာ loading လည်နေလား dropdown menu ဖွင့်ထားလားဆိုတာမျိုးတွေ မသိမ်းရဘူးပေါ့။

2) နံပါတ် ၂ က statelessness ဖြစ်ရမယ်။

client ဖက်က request ပို့လာတဲ့အခါ ဘယ်သူလဲသိရအောင် server မှာသိမ်းထားတာမျိုး မလုပ်ရဘူး။ HTTP request ရဲ့ state တွေကို server မှာသိမ်းမထားရဘူးပေါ့။ အဲဒီအစား request ထဲမှာ ကိုယ်ဘယ်သူလဲဆိုပြီး identify လုပ်လို့ရမယ့် token ဖြစ်စေ၊ cookie ဖြစ်စေ နောက် credential တွေဖြစ်စေ ရှိရမယ်။ ဒါပေမယ့် application အများစုကတော့ session တွေဆောက်ပြီးသိမ်းကြတယ်။ ဒါက မကောင်းတာ မဟုတ်ဘူး ဒါပေမယ့် REST ကိုတော့ ချိုးဖောက်သွားတယ်။

3) နံပါတ် ၃ က Uniform Interface ဖြစ်ရမယ်။

resource တခုစီမှာ URI ရှိရမယ်။ တနည်းပြောရရင် identifiable path ရှိရမယ်ပေါ့။ ပြီးတော့ URI တွေကို တမျိုးကိုတခု လျှောက်ပေးနေလို့ မရဘူး။ ဥပမာ /books, /authors, /shelves/2 တညီတညာတည်း ပေးရမယ်။ HTTP verb တွေသုံးပြီး resource manipulation လုပ်ရမယ်။ books/1 ကိုဖျက်ချင်ရင် delete-book/1 GET ဆိုပြီး မဖြစ်ရဘူး။ books/1 DELETE ဖြစ်ရမယ်။ Respone အတွက် Status Code တွေ သေချာပေးရမယ်။ Error တက်တာကို 200 လို့ပြန်ပြီး payload ထဲကျမှ 404 လို့ မလုပ်ရဘူး။ Error Message တွေကိုလည်း သေချာရေးရမယ်။

4) နံပါတ် ၄ က Layered Architecture ​ဖြစ်ရမယ်။

client နဲ့ server ကြား ဆက်သွယ်တဲ့အခါ ပါဝင်ပတ်သက်နေတဲ့ ရှုထောင့်တွေ အများကြီးရှိတယ်။ security, distribution, datasource စသဖြင့်။ ဒါတွေ အကုန်လုံးကို တနေရာတည်းမှာ အကုန်ပေါင်းထားစရာ မလိုပဲ program တွေအလွှာလိုက် အလုပ်လုပ်နိုင်ရမယ်။ ဥပမာ SSL termination ကို server program မှာမလုပ်ပဲ proxy မှာလုပ်လို့ရရမယ်။ ဒါမှမဟုတ် application data ကို database server ကယူရင်ယူရမယ်။ client ဖက်က ဒါတွေကို မမြင်ရပဲ တသားတည်း transparent ဖြစ်နေရမယ်ပေါ့။

5) နံပါတ် ၅ က cacheability ကိုပြောတယ်။

client အနေနဲ့ server ဆီက /books/123 နဲ့ စာအုပ်တအုပ် တောင်းကြည့်ရင် လက်ခံအပြီးမှာပဲ ဆာဗာပေါ် data ပြောင်းသွားနိုင်တယ်လို့ မှတ်ယူရမယ်။ ကိုယ့်သဘောနဲ့ကိုယ် ပုံသေဒါပဲလို့ မှတ်ထားလိုက်တာမျိုး မလုပ်ရဘူး။ အဲလို cache ထားလို့ရမယ့် resource ဆိုရင် server ဖက်က ဘယ်လို cache ထားလို့ရသလဲ အတိအကျ ကြေညာရမယ်။ client ကလည်း ဒါကို လိုက်နာရမယ်။

6) နံပါတ် ၆ က code on demand တဲ့။

Browser ထဲမှာ animation တွေ၊ UI logic တွေနောက်ပြီး client-side validation အတွက် rule တွေစသဖြင့် လိုအပ်ရင် server ကပို့လာတာကို client ဖက်မှာ စနစ်တကျ မှန်မှန်ကန်ကန် အလုပ်လုပ်နိုင်စေရမယ်။

Web Developer လုပ်ရင် HTTP နဲ့ကော၊ REST API နဲ့ပါကင်းကွာလို့ရမှာ မဟုတ်ဘူး။ ဒါကြောင့် ခုပြောထားတဲ့ အခြေခံလောက်တော့ သဘောပေါက်ဖို့ လုပ်ထားကြရမယ်။