အခုတလော ရုံးမှာ Restful API server ပိုင်းကို ရေးနေရတယ်။ အဲဒီမှာ CodeIgniter Routing Structure နဲ့ အဆင်မပြေတာကို တွေ့လာရတယ်။ Restful API တွေက Controller နဲ့ Model ပဲရှိတယ်။ view ဆိုတာက JSON သို့မဟုတ် XML return ပြန်တဲ့ page ပဲ ရှိတယ်။ အဲဒီတော့ API server ပိုင်းရေးတဲ့ အခါမှာ MVC pattern ဆိုတာက သိပ်အရေးပါတာမဟုတ်ဘူးဆိုတာကို သတိထားမိတယ်။

CodeIgniter ရဲ့ structure က

http://www.domain.com/controller/action/parameter/parameter

controller ကတော့ ရှင်းတယ်။ file တစ်ခု နဲ့ ရေးရလို့။ အဲလိုပဲ action ကလည်း function တစ်ခုနဲ့ ရေးရတော့ တော်တော်လေးကို ရှင်းတယ်။ code ကို ပြန်ဖတ်ရတာလည်း နားလည်တာပေါ့။ သို့ပေမယ့် API တွေ ရေးရတော့ အခုလို ဖြစ်သွားတတ်တယ်။

http://www.domain.com/users/:username/
http://www.domain.com/users/:username/blogs/
http://www.domain.com/users/:username/blogs/:id/
http://www.domain.com/users/:username/blogs/:id/coments/
http://www.domain.com/users/:username/blogs/:id/coments/:id

/:username ဆိုရင် သက်ဆိုင်ရာ user ရဲ့ data တွေ ထွက်လာမယ်။
/:username/blogs ဆိုရင် သူ့ ရဲ့ blog list ထွက်လာမယ်။
/blogs/:id ဆိုရင် blog တွေထဲကမှ id တစ်ခုအတွက် data ထွက်လာမယ်။
/blogs/:id/comments ဆိုရင် comments အကုန်ပေါ့။
/blogs/:id/comments/:id ဆိုရင်တော့ comments တစ်ခုအတွက် id ပေါ့။

အဲဒီမှာ စပြီး ပြဿနာ ဖြစ်တာကတော့ controller က dynamic ဖြစ်နေတာပဲ။ /users/name ဆိုပြီး သုံးပါလားလို့ ဆိုလို့ရပေမယ့် link လမ်းကြောင်းက developers အချို့အတွက် complain တက်စရာ ဖြစ်သွားမှာ အမှန်ပဲ။ ကျွန်တော့် အနေနဲ့လည်း /users/:username ကို /users/name/:username ထက် ပိုသဘောကျတယ်။ တိုသလို လွယ်တယ်။ /name ထည့်လိုက်တဲ့အတွက် /id ကော မရှိဘူးလားဆိုပြီး မေးခွန်းက ရှိလာပြန်တယ်။ Controller ကို သတ်မှတ်လို့ မရတဲ့အတွက် စကတည်းက index မှာပဲ စရမှာပဲပေါ့။ index မှာ username ကို စစ်ပြီးတော့ ရှိခဲ့ရင် သက်ဆိုင်ရာ user ရဲ့ data ကို ပြန်ခေါ်ပြပေးရုံပဲ။

ဒီအထိ ရှင်းပါသေးတယ်။ /blogs ဆိုတာကို ထပ်ထည့်လိုက်တော့ သက်ဆိုရင် user information ကို မပြပေးရတော့ပဲ /blogs လာပြီဆိုရင် blog အားလုံးရဲ့ list ကို ပြဖို့ condition ထပ်ရေးရပါတယ်။

/blogs/:id ဆိုရင် blogs id ကို ရှိမရှိ ထပ်စစ်ရပါမယ်။ အဲဒီ blog id ကလည်း လက်ရှိ username ရဲ့ blog id ဟုတ်မဟုတ် ထပ်စစ်ရပါမယ်။ နောက်ဆုံး /blogs/:id/comments/:id အထိ ကို ရေးတဲ့အခါမှာ condition တွေ အများကြီး သုံးရပါမယ်။ အကုန်လုံးက index() function ထဲမှာ စစ်ထားရပါမယ်။ တနည်းပြောရင် controller/action အပြင်

controller/controller/action ဖြစ်သွားတဲ့အခါရှိသလို /controller/controller/controller/action ဆိုပြီး ရှိသွားတဲ့အခါလည်း ရှိပြန်ကော။ တနည်းပြောရင် url က ရှည်သွားတဲ့အခါမှာ CodeIgniter framework ပုံစံက အရမ်းကို ရှုပ်ထွေးကုန်တာ အမှန်ပဲ။

အဲလိုပဲ CodeIgniter ကို အခြေခံထားတဲ့ Ava framework ပုံစံက လည်း ရှုပ်ထွေးကုန်တယ်။ အစက Restful အတွက် ဆိုပြီး သီးသန့် RestController ထည့်ထားပေမယ့် တကယ်တန်း link တွေက အရမ်းကို ရှည်လာတဲ့ အခါမှာ အဆင်မပြေတော့ပါဘူး။

ဒီနေ့ ဘာကို သွားတွေ့မိသလဲဆိုတော့ Sinatra ပုံစံကို ယူထားတဲ့ Slimframework ဆိုတာကိုပါ။ တော်တော်များများကတော့ slim အစား limonade ကို recommend လုပ်ကြတယ်။ Documentation ကို ကြည့်ကြည့်တာကတော့ limonade က ပိုပြည့်ပြည့်စုံစုံ ရေးထားပေမယ့် limo လို အစိမ်းရောင်ကြီး သုံးထားတော့ documentation ကို ကျွန်တော့် မျက်လုံးက ကြာကြာမဖတ်နိုင်ဘူး။ limonade မှာ သုံးထားတဲ့ structure ကို သိပ်သဘောမကျလှဘူး။ ကျွန်တော်ကတော့ Slimframework မှာ သုံးထားတဲ့ structure ကို သဘောကျမိတယ်။

Slim နဲ့ hello world ကို ဒီလိုရေးရပါတယ်။ GET , POST , PUT , DELETE method တွေကို သတ်မှတ်ပြီးသားပါ။ ဒါကြောင့် GET ဖြစ်လား POST ဖြစ်လား PUT ဖြစ်လား DELETE ဖြစ်လား စစ်ရတဲ့ အလုပ်တော့ သက်သာသွားတယ်။

Sinatra ရဲ့ routing ပုံစံကို express ,node web framework ကို လေ့လာခဲ့တုန်းက သိခဲ့တယ်။ အဲဒီကတည်းက တော်တော်သဘောကျမိခဲ့တာ။ အဓိက သဘောကျတဲ့ အချက်ကတော့ routing ပုံစံပဲ။ router ကို မိမိသဘောကျ သတ်မှတ်ထားပြီး ဒါလာရင် ဒီ function သွားဆိုပြီး ရေးလို့ရလို့ပါပဲ။ လက်ရှိ ကျွန်တော် CodeIgniter Router မှာ ကြုံနေရဲ့ ပြဿနာတွေကို Sinatra ပုံစံအတိုင်းဆိုရင် လွယ်လွယ်လေးနဲ့ ဖြေရှင်းလို့ရပါလိမ့်မယ်။ အဆင်ပြေတယ်ဆိုရင် Slimframework လေးကို လေ့လာပြီး နောက် လုပ်မယ့် projects ရောက်ရင် ပြောင်းသုံးမယ်လို့ စဉ်းစားထားတယ်။ အခု projects တွေကတော့ နောက်ဆုတ်ဖို့ အချိန်မရှိတော့ဘူး။ code တွေက ရှုပ်ထွေးနေပေမယ့် ကောင်းကောင်း အလုပ်လုပ်နေတယ်။ သို့ပေမယ့် slimframework ထက် node က express framework ကို ပိုသဘောကျနေမိတာ အမှန်ပဲ။ သို့ပေမယ့် node.js က mysql နဲ့ တွဲသုံးရတာ အချို့ကိစ္စတွေ တော်တော်လက်ပေါက်ကပ်တာတော့ အမှန်ပါပဲ။