Part 1 ကို အရင် ဖတ်ရန်

Ava framework ကို ဒီမှာ download ချလိုက်ပါ။ ရလာတဲ့ zip file ကို localhost အောက်မှာ testRest ဆိုပြီး ပေးထားပါတယ်။ zip file ထဲက file တွေအားလုံးကို testRest အောက်ကို ပို့လိုက်ပါတယ်။

ပြီးရင် http://localhost/testRest ဆိုပြီး ခေါ်ကြည့်ရင် အောက်ကလို မြင်ရပါမယ်။

ကဲ .. ကျွန်တော်တို့တွေ စရေးလို့ရပါပြီ။

/system/application/controller အောက်က file တွေကို ဖျက်လိုက်ပါ။
/system/application/model အောက်က file နှင့် /system/application/view အောက်က file တွေပါ အပါအဝင်ပေါ့။

ပြီးရင် /system/config/development.php မှာ config လုပ်ရပါမယ်။

const base_url="http://localhost/testRest";
const home_controller = 'posts';

ပြီးရင် database config ကို ပြင်ပါမယ်။ ကျွန်တော်က rest ဆိုတဲ့ database မှာ posts table ကို ဆောက်ထားတာပါ။ ဒါကြောင့် ဒီလိုရေးထားပါတယ်။

const db_host="localhost";
const db_name="rest";
const db_user="root";
const db_password="root";

ဆိုပြီး ပြင်လိုက်ပါမယ်။ ဘာဖြစ်လို့လည်းဆို​တော့ posts ဆိုတဲ့ controller ကို ကျွန်တော်တို့ home controller အနေနဲ့ သတ်မှတ်ထားပါတယ်။ base_url ကိုလည်း http://localhost/testRest ဆိုပြီး ပြင်လိုက်ပါတယ်။

/system/application/controller အောက်မှာ posts.php ဆောက်ပါမယ်။ posts.php မှာ အောက်ကလို ရေးလိုက်ပါမယ်။

အဲဒီ code မှာ

$this->get_route("/","home");

ဆိုတာကတော့ get method ကို အသုံးပြုမယ်။ / ဆိုတဲ့ ပတ်လမ်းကြောင်း တနည်းပြောရင် /posts ဆိုတာကို လာရင် home function ကို ခေါ်မယ်။

Ava ရဲ့ route ပုံစံက

http://domain.com/controller/

controller အောက်မှာမှာ ကျွန်တော်တို့တွေ ဘယ်လမ်းကြောင်းလာရင် ဘယ် function ကို ခေါ်ဆိုပြီး ရေးထားတာပါ။

/ ဆိုတာကတော့ controller/ ကို ပြောတာနဲ့ အတူတူပါပဲ။

posts ဆိုတဲ့ controller အောက်မှာ ဖြစ်တဲ့အတွက်ကြောင့် /posts ကို ခေါ်တာနဲ့ အတူတူပါပဲ။

ကျွန်တော်တို့တွေ get,post,put,delete တွေအတွက် routing နဲ့ function တွေကို

• get_route
• post_route
• put_route
• delete_route

ဆိုပြီး ခေါ်သွားပါတယ်။

$this->run(object)

မှာတော့ ဘာ object မှာ function တွေ ရှိသလဲဆိုတာကို ပြောထားတာပါ။ လက်ရှိ controller ထဲမှာပဲ function တွေ ရေးထားရင်တော့ $this ကို အသုံးပြုနိုင်ပါတယ်။ ကျွန်တော်က function တွေကို သီးသန့် model ခွဲထုတ်လိုက်ပြီး postsfun ဆိုပြီး model နာမည်ပေးထားပါတယ်။ ဒါကြောင့်

$this->run($this->postsfun);

ဆိုပြီး ရေးထားတာပါ။

နောက်တဆင့် အနေနဲ့ ကျွန်တော်တို့ postfun Model ကို ရေးကြည့်ရအောင်။ အရင်ဆုံး postfun.php ကို /system/application/model/ အောက်မှာ သွားဆောက်လိုက်ပါ။ ပြီးရင် ဒီလို ရေးထားလိုက်ပါ။

function တွေ အားလုံးကို ချရေးထားတာပါ။ /:id ဆိုပြီး ခေါ်ထားတဲ့ ပတ်လမ်းကြောင်းတွေကိုတော့ $params ဆိုပြီး parameter ထည့်ထားပါတယ်။

/:id ကို ခေါ်ချင်ရင် $params['id'] ဆိုပြီး ခေါ်လိုက်ရင် ရပါတယ်။

function တွေကို ချမရေးခင်မှာ posts_model တစ်ခု တည်ဆောက်ရအောင်။ posts_model က posts အတွက် လိုအပ်တာတွေ စုစည်ထားတာပါ။

posts_model.php ကို /system/application/model မှာ သွားဆောက်လိုက်ပါ။

Ava မှာ database အတွက် သီးသန့် class ကို အသုံးပြုထားပါတယ်။

database ကနေ ယူချင်ရင်တော့

$this->db->get('table');// SELECT * FROM table 

WHERE တွေ စစ်ချင်ရင်တော့

$this->db->where("field",$value)

Insert လုပ်ချင်ရင်တော့

$array['field']=$value;
$array['field2']=$value;
$this->db->insert('table',$array);

နဲ့ အသုံးပြုပါတယ်။

posts_model တစ်ခုလုံးကို ရှင်းရှင်းလေးပါ။ ဖတ်ကြည့်လိုက်ရင် နားလည်ပါလိမ့်မယ်။ ထည့်တယ်။ ဖတ်တယ်။ ပြင်တယ်။ ဖျက်တယ်။ ဒါလေးပဲ ပါပါတယ်။

အခု postsfun ကို ပြင်ကြည့်ရအောင်။

Ava မှာ model ကို $this->load->model နဲ့ ခေါ်ပြီးရင် $this->modelname နဲ့ model က function တွေကို ခေါ်လို့ရပါတယ်။ ဥပမာ။။

$this->load->model('modelname');
$this->modelname->modelFunction()

အဲလိုမျိုး posts_model ကို ခေါ်ထားတာ တွေ့မှာပါ။

$this->io->write ကတော့ json အတွက်ပါ။

$this->io->write($status,$array)

status code နဲ့ array object ထည့်ပေးလိုက် json အနေနဲ့ ထုတ်ပြပေးမှာ ဖြစ်ပါတယ်။

GET , POST , PUT , DELETE တို့ရဲ့ parse လုပ်တဲ့ data တွေကို လိုချင်ရင်တော့

$this->io->get('var');
$this->io->post('var');
$this->io->put('var');
$this->io->delete('var');

နဲ့ အသုံးပြုလို့ရပါတယ်။

အခု example မှာ POST နဲ့ PUT မှာ parameter က title နဲ့ content ပါ။

အခု စမ်းသပ်ဖို့အတွက် Firefox addon RESTClient ကို download ချလိုက်ပါ။ add on သွင်းပြီးသွားရင် Tool > RESTClient ကို ဖွင့်လိုက်ပါ။

အရင်ဆုံး post method ကို စမ်းပါတယ်။ RESTClient မှာ post method အတွက် Request Header ဖြည့်ပေးရပါမယ်။

Content-Type : application/x-www-form-urlencoded

ထည့်မှာသာ POST method က အလုပ်လုပ်မှာပါ။

POST method ကို title နဲ့ content ထည့်ပြီး run လိုက်ရင် အောက်ကလို မြင်ရပါမယ်။

POST ပြီးသွားရင် GET နဲ့ ပြန်ပြောင်းခေါ်ကြည့်တဲ့အခါ posts တွေ အားလုံးကို တွေ့ရမှာပါ။

အခု post တစ်ခု တည်းကို GET နဲ့ ခေါ်ကြည့်ပါမယ်။

အခု post ကို ပြင်ပါမယ်။ PUT method ကို အသုံးပြုပါမယ်။

နောက်ဆုံး DELETE လုပ်ကြည့်ရအောင် ဗျာ။

အခုဆိုရင် RESTFUL နဲ့ JSON result တွေကို Ava framework ကို အသုံးပြုပြီး လွယ်လွယ်လေး လုပ်လို့ရပါတယ်။ အခုတလော လုံးဝ မအားတာကြောင့် လောလော နဲ့ ရေးထားတာမို့ အဆင့်တွေ အများကြီး ကျော်သွားတဲ့အတွက်ကြောင့် အခု မှ စလေ့လာကာစ လူတွေ နားလည်ဖို့ ခက်ခဲပါလိမ့်မယ်။ CodeIgniter ကို လေ့လာထားသူတွေအနေနဲ့ကတော့ လွယ်လွယ် ကူကူ တီးခေါ်မိပါလိမ့်မယ်။

Code ကိုတော့ အောက်မှာ ရယူနိုင်ပါတယ်။

Download

ကြာသာပတေးနေ့က ရုံးအလုပ် ကိစ္စကြောင့် Google API ကို သုံးမလား ဆိုပြီး အစည်းအဝေး လုပ်ရင်း တစ်ခါတည်း သုံးလို့ရမရ စစ်ကြည့်လိုက်တာ မမျှော်လင့်ပဲ အချို့ API တွေကို Google က မပေးတော့ဘူးဆိုပြီး သိလိုက်ရတယ်။ ဘယ် API တွေ မရတော့တာလဲဆိုတော့

Shutdown ရက် အတိ အကျမပြောသေးတဲ့ API များကတော့

• Code Search API
• Diacritize API
• Feedburner APIs
• Finance API
• Power Meter API
• Sidewiki API
• Wave API

December 1 , 2011 မှာ ပိတ်တော့မယ့် API တွေကတော့

• Blog Search API
• Books Data API
• Books Javascript API
• Image Search API
• News Search API
• Patent Search API
• Safe Browsing API (v1 only)
• Translate API
• Transliterate API
• Video Search API
• Virtual Keyboard API

အဲဒီ API အားလုံးကို အခုအချိန်မှာတော့ request တွေ အများကြီး လုပ်ခွင့် မပေးတော့ပါဘူး။ Google က ပေးထားပြီးသား API တွေ တော်တော်များများကို ဖျက်သိမ်းလိုက်တော့ လက်ရှိ သုံးထားတဲ့ project တွေ website ကို့လို့ကန့်လန့် တွေ ဖြစ်ကုန်တာ အမှန်ပဲ။ တော်သေးတာက လက်ရှိ Google API ကို သုံးပြီးရေးထားတဲ့ project တွေ တစ်ခု မှ မရှိသေးဘူး။ ကြည့်ရတာ နောက်ဆိုရင် Google လည်း API တွေကို Enterprise level တွေကိုပဲ ပေးတော့ မလား မသိလို့ စဉ်းစားမိတယ်။ ကိုယ့် website မှာ အပေါ်က API တစ်ခုခု သုံးထားတဲ့သူတွေ ဘယ်လို အစားထိုးရမလဲဆိုတာကိုတော့ ဒီ ရက် အတွင်းမှာ အဖြေရထားသင့်နေပြီ။

source: http://www.readwriteweb.com/archives/google_announces_apis_scheduled_for_shutdown.php

Application programming interface (API) ဆိုတာ ဘာကြီးတုန်း။ အခုခေတ်က API တွေ သုံးတတ်ရမယ်ဆို။ API ကို ဘယ်မှာ လေ့လာရမှာလဲ။ အဲလိုမေးခွန်းတွေမှာ API ကို ဘယ်မှာ လေ့လာရမလဲဆိုတဲ့ မေးခွန်းကို ဘာပြန်ပြောရမှန်းမသိဘူး ဖြစ်လောက်အောင်ပဲ။ API ကို ဘယ်မှာ လေ့လာရမလဲဆိုတဲ့ မေးခွန်းမေးတဲ့ သူဟာ API ဆိုတာ အခုမှ ကြားဖူးနားဝ ရှိဘူးပြီးတဲ့ ပုံပေါ်ပါတယ်။ ဘာပဲ ပြောပြော လေ့လာချင်စိတ် ရှိတဲ့အတွက်တော့ သိလာနိုင်ပါတယ်။

API ကို သိချင်ရင် Wiki မှာ ဖတ်ကြည့်ပေါ့ကွာလို့ လွယ်လွယ်ပြောလိုက်ရပါတယ်။ သို့ပေမယ့် API ဆိုတာ ဘာကြီးမှန်း မသိတဲ့သူကို wiki မှာ ဖတ်ခိုင်းလည်း လည်နေမယ်လို့ထင်ပါတယ်။ API ဆိုတာကတော့ Application တွေ နဲ့ Service တစ်ခုခုကို ကြားခံဆောင်ရွက်ပေးတဲ့ အရာလို့ သတ်မှတ်လို့ရပါတယ်။

ဥပမာ ။ ။ Program Windows က service တစ်ခုခုကို ယူသုံးချင်တယ်။ အဲဒီအခါ Windows API ကနေ တဆင့်လှမ်းခေါ်ဖို့လိုပါတယ်။ Windows API က ဘယ် application programming ကနေ မဆို လှမ်းခေါ်လို့ ရအောင် ဖန်တီးထားပါတယ်။ ဒါက သဘောပြောပြတာပါ။ တနည်းထပ်ပြောရင် Application ကို ထပ်ပြီး Implement လုပ်လို့ရအောင် library တွေ ထုတ်ထားပေးတဲ့ သဘောပေါ့။ ဒီလောက်ဆိုရင် application programming သမားတွေ သဘောပေါက်ပါလိမ့်မယ်။ web developer တွေ ထက်စာရင် application programmer တွေက API နဲ့ စိမ်းပါတယ်။ ကျွန်တော်ကတော့ Web Developer ဖြစ်တော့ Web API တွေကို ပဲ သုံးပါတယ်။

Web API နဲ့ ပတ်သက်ပြီး လွန်ခဲ့တဲ့ ၈ လ လောက်က ရေးထားတဲ့ Web Service , Web API ဆိုတဲ့ post လေး ရှိပါတယ်။ အခုခေတ်မှာ Web Development လုပ်တဲ့အခါမှာ facebook connect မချိတ်ရင် openid မသုံးရင် သိပ်ပြီး အဆင်မပြေတော့ဘူး။ Web Sites တော်တော်များများမှာ facebook connect , openid တွေ ပါလာပါပြီ။ Single Sign One တွေကို အသုံးပြုလာကြပြီ။ ဒါကြောင့် အခုခေတ်မှာ API ကို မဖြစ်မနေ သိထားဖို့ လိုလာပြီ။ လက်ရှိ ကျွန်တော်ကတော့ အလုပ်မှာ Facebook Graph API နဲ့ Google API ပိုင်းတွေကို ရေးရတာတွေ ရှိပါတယ်။ Google API က အများကြီး ရှိပါတယ်။ သို့ပေမယ့် တစ်ခုကို သဘောပေါက်သွားရင် အခြားဟာတွေ ရေးဖို့လွယ်သွားပြီ။ Google API ထဲမှာ အသုံးများတာက Google Map API ပါ။ အဲဒါကြောင့် ကျွန်တော် အပေါ်မှာ ပြောထားတာပါ။ API ကို ဘယ်မှာ လေ့လာလို့ရမလဲ ဆိုတဲ့ မေးခွန်းအတွက် အဖြေမရှိဘူးဆိုတာ။ ဘယ် API ကို လေ့လာချင်တာတုန်း။ Google API လို့ ထပ်ပြောလိုက်ရင်။ ဘယ် Google API တုန်း ဆိုပြီး ထပ်မေးရမယ့် ကိန်းပါ။ Google Map API လို့ ထပ်ပြောလာရင်။ ဒါများ documentation ရှိတာပဲ ကိုယ့်ဘာသာ ကိုယ်ဖတ်ပေါ့။ API ကို သင်တန်းတက် သလိုမျိုး သင်လို့ မရဘူး။ သင်တန်းလည်း သွားတက်နေလို့မရဘူး။ Google Map API ပဲ ကြည့်။ အခုဆို V3 တောင် ရောက်သွားပြီ။ v3 မှာ အပြောင်းအလဲတွေ နည်းနည်းများတယ်။ ပိုပြီးတော့လည်း ကောင်းလာတယ်။ v2 က အချို့ code တွေ အလုပ်မလုပ်တာကိုလည်း တွေ့ရတယ်။ Facebook API ဆိုလည်း အရင်က API နဲ့ အခုလက်ရှိ Graph API မတူတော့ဘူး။ API ကို တတ်ချင်ရင် သိချင်ရင် ဘယ် API ကို သုံးချင်တာလဲ။ အဲဒီအတွက် Documentation တွေ ရှိထားပြီးသားပါ။ ဖတ်ပြီး လေ့လာလို့ရပါတယ်။

API တွေက ဘာလဲဆိုတော့ လက်ရှိ application ပေါ်မှာ ထပ်ပြီး implement လုပ်လို့ရအောင် ထုတ်ပေးတာပါ။ Twitter API ကြောင့် twitter client တွေ ရေးလို့ရလာတယ်။ facebook api ကြောင့် facebook connect တို့ publish stream တို့ လုပ်လို့ရလာတယ်။ Google Map API ကို သုံးပြီး ကိုယ့် website မှာ google map ကို ထည့်သွင်းလို့ရတယ်။ ဒါက API တွေရဲ့ အကျိုးကျေးဇူးတွေပဲ။ ထပ်ရှင်းရရင် … ဥပမာ။။ Ornagai ပေါ့ဗျာ။ Ornagai website က data တွေ လိုချင်တယ်။ ရှိပါတယ်။ tsv နဲ့ ယူလေ။ live data လိုချင်တာ။ ကျွန်တော့် sites ကနေ ရှာလိုက်ရင် Ornagai ကြီး သွားမဖွင့်ချင်တော့ဘူးလေဗျာ။ ကျွန်တော့် site မှာပဲ result ပြချင်တာဗျ။ အဲဒါဆို ဘယ်လိုလုပ်မလဲ။ ကျွန်တော်က သူ့ကို database ကြီး ဖွင့်ပေးလိုက်ရမလား။ database ထဲမှာ user information တွေ ရှိတယ်လေဗျာ။ ဘာလို့ ဖွင့်ပေးရမှာလဲ။ သူက စာလုံးပဲ ရှာချင်တာပေါ့။ ဟုတ်ပြီ။ စာလုံးရှာဖို့ အတွက် Ornagai API ကို ထုတ်ပေးလိုက်တယ်။ ရော့ ornagai api ကို သုံးပြီး ကိုယ့် website ထဲမှာ ပေါ်အောင် ရေး။ ornagai api ကို သုံးပြီး online application တွေ client application တွေ ရေးချင်ရေးလို့ရလာတာပေါ့။

အဲဒါက API ပဲ။ API ပေးတော့ ပြဿနာတစ်ခုက လက်ရှိ server က ပိုပြီး အလုပ်လုပ်ရတာပေါ့။ အဲဒီတော့ ဘယ်လိုလုပ်မလဲ။ API Key ထုတ်ပေးပြီး ဒီ application က ၁ နာရီ ကို ဘယ် နှစ်ကြိမ်ပဲ request ရှိတယ်ဆိုတာကို သတ်မှတ်တာတွေ လုပ်လာရပြီ။ twitter public stream က IP တစ်ခုကနေ ၁ နာရီကို အကြိမ် ၁၅၀ ပဲ request လုပ်ခွင့်ပေးသလိုပေါ့။ Client application က လူသုံးအရမ်းများလာရင် ဒီ API Key က request တွေ အရမ်းများတယ်။ အဲဒီ အတွက် သူ့ app ကို စစ်ဖို့ လိုတယ်ဆိုတာကို သိနိုင်သလို ဒီ request ထက်ပိုသွားရင် ပိုက်ဆံ ပေးရမယ်ဆိုပြီး စီးပွားရေး ပုံစံတွေ ပြောင်းလဲလာတာတွေလည်း ရှိပါတယ်။

တနည်းပြောရင် API ကို လေ့လာချင်တယ်လို့ ပြောနေတဲ့သူတွေအတွက် ဘယ် API ကို စလေ့လာမလဲဆိုတာကို စဉ်းစားဖို့လိုပါတယ်။ ရိုးရိုးလွယ်လွယ်ကတော့ Google Map API ပဲ။ Facebook connect လည်း SDK သုံးလိုက်ရင် လွယ်ပါတယ်။ Twitter လည်း ထိုနည်းလမ်းကောင်းပါပဲ။ Client Library တွေကို သုံးလိုက်လို့ရပါတယ်။ သို့ပေမယ့် Facebook တို့ Twitter တို့သုံးမယ်ဆိုရင်တော့ RESTful နဲ့ oAuth ကို နားလည် ထားရင် ပိုကောင်းပါလိမ့်မယ်။ RESTful ဆိုတာ ဘာလဲ oAuth ဆိုတာ ဘာလဲဆိုတာကတော့ twitter ကိုလေ့လာရင်းနဲ့ သိလာနိုင်ပါတယ်ဗျာ။ ဘာလို့ RESTful နဲ့ oAuth ကို သိဖို့လိုမှာလဲလို့ မေးလာရင် လက်ရှိ API တော်တော်များများက အဲဒီ ၂ ခုကို အသုံးပြုကြပါတယ်။ wsdl ကော ။ SOAP ဆိုတဲ့ webservice ကကော လို့ ပြန်ပြောကောင်းပြန်ပြောပါလိမ့်မယ်။ သူတို့ကတော့ လက်ရှိ public ချပေးတဲ့ API တွေမှာ အသုံးနည်းသွားပါပြီ။ RESTful က နားလည်ရတာ လွယ်ကူပြီး oAuth ကတော့ ကိုယ့် username နဲ့ password ကို client website ကို ပေးစရာမလိုပဲ login ဝင်နိုင်တဲ့ နည်းပညာလို့ အလွယ်မှတ်လိုက်လို့ရပါတယ်ဗျာ။

subscriber count ကို feed burner ကနေ ယူချင်တာနဲ့ API လေး စမ်းဖြစ်သွားတယ်။ feed burner api မလုပ်ခင် api ကို allow လုပ်ပေးဖို့လိုတယ်။

1. login your feedburner and go to your feed.
2. Go to Publicize tag
3. Go to Awareness Api and active it.

code ကတော့ အောက်က အတိုင်းပဲ။ ဒါပေမယ့် uri ဆိုတဲ့နေရာမှာ ကိုယ့် uri လေး ထည့်ပေးဖို့လိုပါတယ်။

<?php
//get cool feedburner count
$toopen="http://feedburner.google.com/api/awareness/1.0/GetFeedData?uri=saturngod";

$ch = curl_init(); /// initialize a cURL session
curl_setopt($ch, CURLOPT_URL, $toopen );
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true);
$content = curl_exec ($ch);//end get cool feedburner count
curl_close($ch);

$dom = new DOMDocument();
$dom->preserveWhiteSpace = false;
$dom->loadXML($content);
$count=$dom->getElementsByTagName("entry")->item(0)->getAttribute("circulation");
echo $count;
?>

Twitter ကတော့ တော်တော်လွယ်ပါ့။ screen_name မှာ twitter account name ထည့်လိုက်ရုံပဲ။

<?php

$toopen="http://twitter.com/users/show.xml?screen_name=saturngod ";

$ch = curl_init(); /// initialize a cURL session
curl_setopt($ch, CURLOPT_URL, $toopen );
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true);
$content = curl_exec ($ch);//end get cool feedburner count
curl_close($ch);

$dom = new DOMDocument();
$dom->preserveWhiteSpace = false;
$dom->loadXML($content);
$count=$dom->getElementsByTagName("followers_count")->item(0)->nodeValue;
$twitt=$dom->getElementsByTagName("text")->item(0)->nodeValue;

?>

Play in the playground ဆိုလို့ သူငယ်ပြန်သွားတယ်လို့ ထင်ကုန်ကြအုံးမယ်။ မနေ့ညက oAuth ကို ဘယ်လိုလုပ်ရမလဲ မသိလို့ရှာရင်း ရှာရှင်းကနေ playground ထဲကို ရောက်သွားတာပဲ။ webdeveloper forum က playground ထဲမှာ ရှိတယ်ဆိုလို့ playground ထဲ အပြေးသွားကြည့်ရတာပဲ။ playground ထဲရောက်မှ woww… ဆိုပြီး သဘောကျစရာတွေ အပြည့်ပဲဗျ။ ဆော့စရာတွေက များမှ များ။ ခက်တာက ကိုယ်လိုအပ်နေတာပဲ အရင်ဆော့ရတာပေါ့။Playground ဆိုတာက Google Code Playground ကိုပြောတာပါ။ Google က ထုတ်ထားတဲ့ API တွေကို example နဲ့ စုဆောင်းထားတဲ့နေရာလေးပါ။ Google API ကို ဘယ်လိုအသုံးပြုရမလဲ မသိတဲ့သူတွေအတွက် အရမ်းအဆင်ပြေတယ်။ http://code.google.com/apis/ajax/playground/ မှာ သွားကြည့်လို့ရတယ်။ အဲဒီ playground ကတော့ javascript နဲ့ကြီးပဲ။ ကျွန်တော်လိုချင်နေတဲ့ oAuth ကတော့ http://googlecodesamples.com/ အဲဒီမှာ ရှိတာပါ။ တစ်ခါတစ်ခါ google ကို သဘောကျမိတယ်။ အများအားဖြင့်တော့ စိတ်ညစ်တယ်။ Google က သုံးတဲ့ နည်းပညာတွေက နောက်ဆုံးတွေ သုံးတာ များတော့ ကိုယ်လည်း လိုက်မဖတ်နိုင်ရင် သူပြောတာတွေကို နားလည်ဖို့မလွယ်ဘူး။ သူ့ထက်စာရင်  paypal api တို့twitter တို့က ပိုလွယ်တယ်။ ဒါပေမယ့် google က playground ရှိတော့ လေ့လာရတာလွယ်တာပေါ့။ နောက်ပြီး forum support ရှိပေမယ့် အဲလောက် သုံးလို့မကောင်းဘူး။ အများအားဖြင့် ပြန်မဖြေတာများတယ်။ ပြန်ဖြေရင်လည်း အများအားဖြင့် စိတ်ကျေနပ်စရာအဖြေရအောင် မပေးနိုင်ဘူး။ webdeveloper forum က web development အတွက် မေးရတာ တော်တော်ကောင်းတဲ့ forum ပဲ။ oAuth ကို stackoverflow ကို မေးပေမယ့် တော်တော်များများက ကျေနပ်တဲ့အဖြေမရဘူး။ ဥပမာ။။ အခုလို playground လိပ်စာပေးတာမျိုးပေါ့။ Stackoverflow မှာက PHP developer နည်းတာလည်း ပါလိမ့်မယ်ထင်တာပဲ။ မေးနေကျ webdeveloper forum ကိုပဲ သုံးလိုက်တော့ တော်တော်အဆင်ပြေသွားပြီ။ အခုတော့ playground ကြောင့် ပထမ အဆင့်တော့ ရသွားပြီ။ နောက်ဆုံး ၂ ဆင့်ဖြတ်ပြီးရင် oAuth access ရပြီ။ ပြီးရင် GET,POST,PUT,DELETE ကို စမ်းဖို့ပဲ ကျန်တော့တယ်။

အခုမှ သိလိုက်တယ်။ ကျွန်တော် မသိပဲ ပြောင်းလဲသွားတာ အများကြီး ဖြစ်သွားတာပဲ။ ကျွန်တော့်အနေနဲ့ အများကြီး နောက်ကျနေမှန်း အခုတလောမှ သိလိုက်ရတာတွေ ရှိတယ်။ အဓိကတော့ ပြောင်းလဲမှုတွေကို မျက်ခြေမပြတ်မလိုက်နိုင်လိုက်တာလဲပါတာပေါ့။ ကျွန်တော် မသိပဲ ဖြစ်သွားတာတွေက

API

ရန်ကုန်မှာနေတုန်းက API ဆိုလို့ Google Map API ပဲသုံးဖူးတယ်။ အခြား API တွေ သုံးရအောင်လည်း သုံးစရာ နေရာမရှိသလို သုံးဖို့လည်း မစဉ်းစားမိဘူး။ သုံးဖို့လည်း လိုချင်မှ လိုလိမ့်မယ်လို့ ထင်မိနေတာလားတော့ မသိဘူး။ API လောက ဘာတွေ ပြောင်းလဲသွားပြီဆိုတာကို လုံးဝလုံးဝကို မသိလိုက်ဘူး။ Google IO ပွဲတွေကိုလည်း စောင့်မကြည့်တတ်တာပါပါတယ်။ နောက်ပြီး web related conference တွေလည်း မတက်ဘူးဖူး။ နောက်ဆိုရင်တော့ register ဖိုးပေးရပေမယ့် တက်မယ်လို့တော့ ဆုံးဖြတ်ထားတယ်။ အရင်တုန်းက SOAP အသုံးများခဲ့ပါတယ်။ အခုအချိန်မှာတော့ SOAP ဟာ ခေတ်မရှိတော့ဘူးလို့တောင် ဆိုရမလိုဖြစ်သွားပြီ။ REST နဲ့ oAuth ဟာ အရမ်းကို အောင်မြင်လာပါတယ်။ REST နဲ့ oAuth ပြောင်းလဲခဲ့တာလည်း တော်တော်ကြာခဲ့ပါပြီ။ ဒါပေမယ့် အဲဒါကို မသိလိုက်ဘူး။ oAuth နဲ့ တူတဲ့ Filckr Auth , Google’s AuthSub, Yahoo’ BBAuth, Facebook Auth တွေရှိပါတယ်။ Google’s AuthSub ကိုတော့ GET ပိုင်းကိုတော့ စမ်းခဲ့ပြီးပါပြီ။ ဒါပေမယ့် POST,PUT, DELETE ကို စမ်းတာ မအောင်မြင်သေးဘူး။ AuthSub က session token ကြောင့် grand access အမြဲလိုနေတာကိုတော့ သဘောမကျဘူး။ GET,POST ကို သာမာန် web developer တွေသိပေမယ့် PUT,DELETE ကို တော့ သိကြမယ်မထင်ဘူး။ PUT,DELET က HTTP 1.1 မှာ ပါလာတာပါ။

Facebook Connect

နေရာတိုင်းမှာ facebook connect ဖြစ်လာပြီ။ ဒါကိုတော့ အရင်ကတည်းက သတိထားမိတယ်။ Facebook Connect ဆိုတာ ဘယ်လိုရေးမှန်း မသိခဲ့ပေမယ့် နောင်တချိန် အောင်မြင်နိုင်မလား မအောင်မြင်ဘူးလားဆိုတော့ ဝေခွဲမရဘူး။ ရန်ကုန်မှာတုန်းက facebook ကို စိတ်ညစ်တယ်။ facebook connect သုံးလိုက်ပေမယ့် အရမ်းကြာတယ်။ Connection မကောင်းလို့လားတော့ မသိဘူး။ ရန်ကုန်မှာက dial-up ပဲ သုံးဖြစ်တာကို။ Access Kit နဲ့လေ။ အလုပ်စလုပ်တော့ client တော်တော်များများကိုက facebook connect ကို အလိုရှိကြတယ်။ ဟုတ်မှာပေါ့။ connect လုပ်တာက register လုပ်တာထက်တောင် မြန်သေး။ web လောကရဲ့ ပြောင်းလဲနေပြီ ပြောင်းလဲသွားပြီဆိုတာကို ပြောင်းလဲတော့မယ်လို့ ထင်ပြီး ကျန်ခဲ့ဘူးတာပဲလို့ သိလိုက်ရတယ်။

Google App Premier Edition

အရင်တုန်းကတော့ ထင်တယ်။ Premier Edition ကို ဘယ်သူတွေ သုံးမှာလဲပေါ့။ စျေးကလည်း ကြီးပါ့။ ဘာများကောင်းမှာမို့လဲဆိုပြီးတော့။ Standard သုံးရင် ရနေတာပဲလို့ ထင်ခဲ့တယ်။ သို့သော် အထင်နဲ့ လွဲခဲ့တယ်ဆိုတာ ထပ်သိတာပဲ။ Premier Edition ကို သုံးနေတဲ့ company တွေ အများကြီးပါ။ ကျွန်တော်တို့company ကလည်း Reseller ဖြစ်သာကြောင့်လည်း ပါပါတယ်။ Premier Edition ကို သုံးရင် အရင် mail တွေအကုန် merging လုပ်လို့ရတယ်။ Google App Premier Edition မှာ domain share contact ပါတယ်။ အဲဒါတော်တော်လေးမိုက်တယ်။ Premier Edition အကြောင်း အရင်တုန်းကပြောဘူးပါတယ်။ အဓိက standard ထက် သာတာကတော့ API နဲ့ Postini ပဲ။

Gogole Solution Market

Google က သူတို့တင် ငွေယူတာမဟုတ်ဘူး။ အခြား Reseller တွေ developer တွေကိုလည်း ငွေဝင်လမ်းဖန်တီးပေးထားတယ်။ Google App က API တွေထုတ်ပေးပေမယ့် သာမာန် user တွေအနေနဲ့က ဝေးလွန်းတယ်။ company မှာက email ပို့မယ်။ Gtalk သုံးမယ်။ နောက်ပြီး Google Doc သုံးမယ်။ စတာတွေလောက်ပဲ သုံးတတ်ကြတဲ့သူတွေပါ။ အဲဒီအတွက် Developer တွေက သူတို့ Google ပေးထားတာထက် ပိုလိုချင်လာတာတွေကို ဖန်တီးပေးရတယ်။ ဥပမာ။။ Outlook နဲ့ Google Apps Contact ကို Sync လုပ်ချင်တာတို့  နောက်ပြီး doc ကို offline, online sync လုပ်ချင်တာတို့ စတာတွေကို user တွေလိုချင်တဲ့အခါ Developer တွေက ပြန်ရေးပေးရတယ်။ နောက်ပြီး user တွေလိုချင်တာတွေက ရေးပြီးသားရှိနေတတ်တယ်။ Google Solution Marketplace မှာ ရှာလိုက်ရင်ရပါတယ်။ Marketplace ကတော့ အကြီးကြီးမဟုတ်ပေမယ့် မသေးတာတော့ အမှန်ပဲ။ နည်းနည်းခြင်းနဲ့ တအိအိစားနေတာ။ by monthly ပေးဆောင်ရတာတွေ များတယ်။ အဲဒီအတွက် client အတွက်လည်း ငွေတစ်ခါတည်း အများကြီးမကုန်သွားသလို သူ့အနေနဲ့လည်း အလုပ်လုပ်ရတာ အဆင်ပြေတယ်။ အဲလို marketplace တွေ ရှိမယ်လို့ မသိလိုက်တာလည်း ဆိုးတယ်။

Synchronize with cloud computing

Cloud computing ခေတ်စားလာမယ်ဆိုတာ ကြိုတင်တော့ သိပေမယ့် Synchronize လည်း အရေးပါလာမယ်ဆိုတာကို သိပ်ပြီး သတိမထားမိဘူး။ အစက အကုန် web ပေါ်မှာ အလုပ်လုပ်ကြမယ်ပေါ့။ အဲလို ထင်မိတာ။ တကယ်တန်းတော့ အဲလို မဟုတ်ဘူး။ end user တွေအကုန်လုံးက အခုချိန်ထိ offline ကို မက်မောနေတုန်းပဲ။ အင်တာနက်မရှိလည်း သူတို့ အလုပ်တွေလုပ်လို့ရအောင် ဖန်တီးထားချင်တယ်။ အင်တာနက်မရှိလို့ data တွေ access လုပ်လို့မရမှာ ကြောက်ကြတယ်။ အဲဒီအတွက် Synchronize က အရေးပါလာတယ်။ ခုနက ကျွန်တော်ပြောထားခဲ့သလိုပေါ့။ Google Doc က online ပေမယ့် offline ကို လိုချင်ကြတုန်းပဲ။ ဒါကြောင့် Synchronize လုပ်ပေးတဲ့ program တွေ ပေါ်လာတာပေါ့။ ဥပမာ။။ evernote ဆိုရင် အကောင်းဆုံး ဥပမာပဲ။ iPhone,iPodTouch,Blackberry,Windows Mobiles,Android ပေါ်တွေမှာလည်းရတယ်။ ကိုယ့် computer ပေါ်မှာလည်းရတယ်။ အဲ.. mac နဲ့windows ပဲရတယ်။ Linux ပေါ်မှာတော့ မရသေးဘူး။ နောက်ပြီး web ပေါ်မှာလည်းရတယ်။ အမြဲ Synchronize လုပ်ပေးနေတယ်။ အဲဒီအတွက် သူတို့က Synchronize bandwidth ကို monthly အရ ဘယ်လောက်ပဲ လုပ်ခွင့်ရှိတယ်ပေါ့။ ဒီထက်ပိုလုပ်ချင်ရင် ပိုက်ပိုက်ပေးပဲ။ ဒါကလည်း cloud computing ခေတ်ကြီးထဲမှာ ငွေရှာနည်း တစ်နည်းပဲ။ Drop box လည်း ဘာထူးလဲ။ Synchronize လုပ်ပေးတယ်။  ကိုယ့် စက်ထဲမှာကော  online မှာပါ access လုပ်လို့ရတယ်။ အဲ… space ပြည့်သွားရင်တော့ ဝယ်ဖို့ စဉ်းစားပေါ့။

YoutTube

ရန်ကုန်မှာ ကြားရပြီး မခံစားခဲ့ရတဲ့အထဲမှာ youtube ပါတယ်။ youtube သုံးတဲ့ bandwidth က ကြောက်ဖို့ကောင်းတာလည်း ပါတယ်။ ဆိုင်မှာ တစ်ယောက်က youtube ဖွင့်လိုက်ရင် အခြားစက်တွေပါ connection လေးသွားတယ်။ ဘာကြောင့် ဖြစ်သွားမှန်းတော့ မသိဘူး။ ဒီမှာတော့ ကိစ္စမရှိဘူး။ youtube streaming က အရမ်းမြန်တယ်။ အခြား video site တွေ streaming နဲ့ ယှဉ်ရင် မြန်တယ်လို့ ဆိုလို့ရမယ်။ အဲဒါကတော့ အဓိက အောင်မြင်တဲ့ အချက်မဟုတ်သေးဘူး။ အဓိက အောင်မြင်သွားစေတဲ့အချက်က API နဲ့ converting ပဲ။ သူ့ API ကြောင့် video recording တွေကနေ တစ်ခါတည်း တန်းတင်လို့ရတယ်။ ဥပမာ။။ iShowU HD ကနေ record လုပ်ထားတာကို တစ်ခါတည်း youtube ကို တန်းတင်လို့ရတယ်။ mov file ကို တစ်ခါတည်း flv size အမျိုးမျိုး သူ့ဘာသာသူ online မှာပြောင်းတယ်။ MP4 ကိုလည်း တစ်ခါတည်းပြောင်းပေးတယ်။ hardware ကောင်းလို့ မြန်တာကိုတော့ ချီးကျူးစရာမရှိပေမယ့် movie format အမျိုးမျိုးကို flv size ၃ မျိုးနဲ့ MP4 ကို သူ့ဘာသာသူပြောင်းပေးတာကိုတော့ သဘောကျတယ်။ တနည်းပြောရင် user အနေနဲ့ upload တင်လိုက်ရုံပဲလေ။ user ကို အဆင့်အများကြီးလုပ်စရာမလိုပဲ လွယ်လွယ်လေးနဲ့ ပြီးအောင် ပြုလုပ်ပေးထားခြင်းက အဓိကအောင်မြင်ခြင်း သော့ချက်ပဲ။

MZ မှာမေးထားတာလေးကို blog မှာလည်း အခြားသူတွေ သိအောင် ထပ်ဖြေပေးလိုက်ပါတယ်။

ကျတော်က ဒီလိုနားလည် ထားတယ်…
ဥပမာ . Facebook မှာဆိုရင် Game တွေ အများကြီးပါတယ်။ အဲဒီ Game တွေက သာမာန် web programming နဲ့ ရေးလို့ မရဘူးဗျာ။ အဲဒါကို တခြား java ဖြစ်ဖြစ် c ဖြစ်ဖြစ် ရေးထားမယ်ပေါ့။ အဲဒီ အခြေနေမှာဆိုရင် ကို ရေးလိုက်တဲ့ဟာက my application ဖြစ်သွားပြီပေါ့။ အဲဒါကိုမှ web site မှာတင်ချင်တယ်ဆိုတော့ my application ကနေ web application ကိုပြောင်းဖို့ အတွက် web service ကို အသုံးပြုတာလို့ ကျတော်က နားလည် ထားတယ်။ အဲဒီ အတွေးက မှန်ပါသလား။

ခင်မင်စွာဖြင့် စိုင်းထက်

အဲလိုမဟုတ်ပါဘူး။

facebook မှာရေးချင်တယ်ဆို၇င် fbml ကို သုံးပြီးတော့ ရေးရမယ်။ အဆင်အပြေဆုံးကတော့ PHP နဲ့fbml ကို တွဲသုံးပြီး ရေးတာပေါ့။ အဲလိုရေးဖို့အတွက် အရင်ဆုံး facebook မှာ API key ယူရတယ်။ API key ရပြီးတော့မှ PHP ကနေဆိုရင် facebook phplibrary နဲ့ fbml ကို သုံးပြီးရေးရတယ်။ app run တာကတော့ ကိုယ့် host မှာ။ ပြတာကတော့ facebook ကနေပေါ့။ API နဲ့ FBML က အလုပ်လုပ်သွားပေးတာပါ။ API ဆိုတာက facebook နဲ့ ကိုယ်ရေးထားတဲ့ API ကို ကြားခံဆောင်ရွက်ပေးတာပါ။ အဲလို ဆောင်ရွက်ပေးဖို့အတွက် ကိုယ်က facebook site မှာ app register လုပ်ရတယ်။ အဲဒီ အခါ API key ရလာမယ်။ API key ရမှ ဆက်သွယ်လို့ရမယ်။ API key ဆိုတာက security သဘောမျိုးနဲ့ သုံးတာပါ။ ဥပမာ API ကို အသုံးပြုပြီး facebook မှာ ၅ မိနစ် တစ်ခါ post တွေ အလိုအလျောက်တင်နေလို့ရတယ်။ အဲဒီအခါ facebook က ခွင့်မပြုဘူးဆိုရင် ဘယ် API က လာတယ်။ အဲဒီ API ကို ဘယ် user က register လုပ်ထားလဲဆိုတာကို သိပြီး ban လိုက်လို့ရတယ်။

oAuth က နည်းနည်းရှုပ်တယ်။ နည်းနည်းပိုရှင်းတဲ့ AuthSub ကို ပြောတာ ပိုကောင်းမယ်။ AuthSub ဆိုတာက google ရဲ့ နည်းပညာပါ။ oAuth ကို အခြေခံထားတာပဲ။ user တွေရဲ့ contact list ကို site တစ်ခုကနေ ယူတော့မယ်ဆိုပါဆို့။ အဲဒီလိုအခါမှာ user ရဲ့ username နဲ့ pwd ထည့်ရမယ်။ အဲဒီ site က ယုံကြည်စိတ်ချရမှု ရှိချင်မှရှိမယ်။ အဲလိုမျိုးတွေအတွက် oAuth ပေါ်လာတာပါ။ AuthSub က oAuth ထက် ပိုရှင်းအောင် လုပ်ထားပေးတယ်။

Google Contact list ကို web site က request လုပ်လိုက်ရင် google website ကိုရောက်သွားမယ်။ google website မှာ user က login ဝင်။ ဝင်ပြီးတဲ့အခါမှ google က ဒီ site က contact list ကို တောင်းနေပြီ။ မင်းပေးမှာလားလို့ မေးရော။ ကိုယ်က ပေးလိုက်လို့ပြောတဲ့အခါမှ google ကနေ ပေးလိုက်တာ။ အဲဒီ အခါမှာ လာခဲ့တဲ့ site ကိုရောက်သွားရော။ အဲဒီအတွက် session token ပို့လိုက်တယ်။ username နဲ့ pwd တော့ မပို့ဘူး။ session token ဖြစ်တဲ့အတွက် အချိန်အကြာကြီးမရတဲ့အတွက် username နဲ့ pwd ကို site က ခိုးလို့မရတော့ဘူး။ user အတွက်လည်း စိတ်ချရတယ်။ site အတွက်လည်း user ရဲ့ ယုံကြည်မှုကိုရတယ်။

တနည်းပြောရင် သာမာန် web programming နဲ့ပဲ ရေးရတာပဲ။ facebook app လည်း သာမာန် web programming နဲ့ပဲရေး၇တာပဲ။ သက်ဆိုင်ရာ API function တွေကိုတော့ ယူသုံးရတယ်။ ဥပမာ။ facebook API function ကနေ friendlist တွေရနိုင်တယ်။ user information တွေရနိုင်တယ်။ register လုပ်တယ်ဆိုတာက user information ရဖို့ပဲ။ facebook connect သုံးလိုက်တော့ user လည်း register လုပ်စရာမလိုတော့ဘူး site ကလည်း information ရတယ်။ အဲလိုမျိုး web service တွေက အလုပ်လုပ်ပေးတာ။

ဥပမာ။ ။ ကျွန်တော် လက်ရှိရေးနေတဲ့ ornagai ဆိုပါဆို့။ API ကတော့ ရေးနေဆဲ မပြီးသေးဘူး။ API register လုပ်ထားတဲ့သူက ornagai ရဲ့ စာလုံးတွေကို အခြား site ကနေ retrieve လုပ်လို့ရတယ်။ ကျွန်တော့် site ကို လာစရာမလိုပဲနဲ့ API function ခေါ်ပြီး retrieve လုပ်လို့ရမယ်။ အဲဒီအတွက် အခြား site တွေကလည်း စာလုံးတစ်ခုကို mouse ထောက်လိုက်တာနဲ့ ornagai dictionary API ကို ယူပြီး ornagai ကနေ စာလုံးရှာပြီး return ပြန်လာမယ်။ ပြန်လာတဲ့စာလုံးကို ရေးထားတဲ့ app ကနေ ရယူပြီး ပြန်ပြီးပေးတယ်။

Google Map API ကို အသုံးပြုပြီးတော့ မြေပုံပေါ်မှာ ပုံတွေထည့်တာ point တွေထည့်တာ စတာတွေလုပ်လို့ရတယ်။

http://map.etelegram.net.mm

ဆိုရင် Google Map API သုံးပြီးတော့ မြန်မာနိုင်ငံက မြို့တွေကို point တွေနဲ့ ချထားတာ။ အဲလိုလုပ်ဖို့ google map api key ကို အရင်ဆုံး ယူရတယ်။ API key တစ်ခုက register လုပ်ထားတဲ့ site ကပဲ ခေါ်လို့ရတယ်။ http://map.etelegram.net.mm/ က API key ကို http://map.mymap.com.mm ကနေ ခေါ်လို့မရဘူး။  API key တစ်ခု ရယူဖို့က တစ်ခုနဲ့ တစ်ခုမတူဘူး။ Google Map ဆိုရင် site ပဲလိုပေမယ့် facebook ဆိုရင် facebook user ဖြစ်ရမယ်။ သုံးမယ် website လည်းလိုတယ်။

ဒါပေမယ့် Twitter အသုံးပြုတဲ့ REST လိုကျတော့ ဘာမှ မလိုပြန်ဘူး။ oAuth လိုတဲ့အပိုင်းရှိသလို မလိုတဲ့ အပိုင်းရှိတယ်။ user တစ်ယောက်ရဲ့ tweet တွေကို ထုတ်ကြည့်ချင်ရင် twitter ကပေးထားတဲ့ REST web service ကနေ ထုတ်လိုက်လို့ရတယ်။ ဘယ် site ကနေ ဖြစ်ဖြစ် ဘယ် app ကနေ ဖြစ်ဖြစ် ထုတ်ယူလို့ရပါတယ်။ ဒါပေမယ့် ကိုယ့် status တင်တော့မယ်ဆိုရင် oAuth လိုအပ်ပါတယ်။ oAuth သဘောတရားက AuthSub သဘောတရားနဲ့ ဆင်တူပါတယ်။ SOAP ဆိုတာက ထပ်ရှိသေးတယ်။ SOAP ကတော့ အခုချိန်မှာ ခေတ်သိပ်မရှိတော့ဘူး။ သုံးတဲ့လူလည်း တော်တော်နည်းသွားပြီ။

API တွေ web service တွေကြောင့် ဘာလုပ်လို့ရလဲဆိုတော့ sync တွေ လုပ်လို့ရလာတယ်။ ဥပမာ Google Calendar ဆိုပါဆို့။ Google Calendar က online ပဲရတယ်။ App တစ်ခုရေးပြီး Google Clanedar API ကို ယူသုံးလိုက်ပြီး data တွေ အကုန်ဆွဲချလိုက်လို့ရတယ်။ နောက်ပြီးတော့ APP မှာ ထည့်ထားတာတွေကို Google Calendar API ကနေ တင်ပေးလိုက်လို့ရတယ်။ Syn လုပ်ပြီးသွားရင် Google Calendar မှာရှိတာတွေနဲ့ ကိုယ့် app မှာရှိတာတွေနဲ့ အတူတူဖြစ်သွားပြီ။

ဒီလောက်ဆို၇င် web service , web API တွေအကြောင်း နားလည်ပြီလို့ ထင်ပါတယ်။

ကျွနု်ပ် web service ဆိုသည်မှာကို မြန်မာမှုမပြုတတ်ခြင်းမှာ ကျွနု်ပ်ညံ့ခြင်းသာ ဖြစ်ပေတော့သည်။ Web service နှင့် web api ဘာမှ မကွာချေ။ သို့သော် မတူချေ။ ထိုအကြောင်းကိုလည်း သေချာအောင် မရှင်းပြတတ်ခြင်းမှာလည်း ထပ်ညံ့ပြန်လေသည်။ oAuth နှင့် AuthSub ကွာသည်။ ဘယ်လိုကွာကြောင်း စာနှင့်ရေးပြီး မရှင်းတတ်သေးသောကြောင့် သေချာမသိကြောင်း သိသာလှပေသည်။ ထို့ကြောင့် REST ကို သုံးဖူးသော်လည်း REST ဆိုသည်မှာ အဘယ်နည်းဟု မေးသောအခါ အဓိပ္ပာယ်ပြည့်စုံစွာ မဖြေကြားနိုင်သောကြောင့် စာမေးပွဲဆိုလျှင် ကျွန်ုပ်ကျလေပြီ။

Google ကတောင် ညွှန်းဆိုသော Zend Framework အား အခုချိန်ထိ မသွင်းတတ်သေးသည်မှာ ကျွန်ုပ်၏ လေ့လာမှု အားနည်းခြင်းကို ဖော်ပြနေလေသည်။ REST server အတွက် code အသင့်ရှိသော်လည်း တစ်ခါမှမရေးဖူးသည့်အတွက် မသိပဲ အော်နေသော် လူညံ့တစ်ယောက် ပမာဖြစ်ပေတော့သည်။ ကျွန်ုပ်၏ ညြံ့ပန်လေသည်။ Zend Library ဖြင့် Gdata ကို လွယ်ကူစွာ သုံးတတ်သော်လည်း AuthSub မှ AuthSub ဖြစ်နေသော ကျွန်ုပ်စိတ်အား ကျွန်ုပ်ပြောင်းလဲ နိုင်စွမ်းမရှိသောကြောင့် ကျွန်ုပ်၏ စိတ်အင်အားဟာလည်း ညံလှပေသည်။ AuthSub နှင့် oAuth ၂ ခု အား ၄ ရက်တိုင်တိုင် လေ့လာခဲ့သော်လည်း AuthSub ၏ GET ဖြင့်သာ data ယူနိုင်ခဲ့ခြင်းမှာ ကျွန်ုပ်၏ ညံ့ဖျင်းမှုကြောင့်လို့ ဆိုနိုင်လေသည်။ PHP Library မရှိသောအခါ Python ကို background ထားကာ အလုပ်လုပ်ခြင်းမှာ ကျွန်ုပ်၏ ညံ့ဖျင်းမှုပင်။ API အတွက် PHP Library ကိုယ်တိုင် လွယ်လင့်တကူ ချက်ခြင်းကောက်မရေးနိုင်ခြင်းမှာ ကျွန်ုပ်၏ လေ့လာမှု စွမ်းအား အတော့်ကို အားနည်းသည်ခြင်းကို ဖော်ပြရာ ရောက်လေ၏။

ကျွန်ုပ်မသိပဲနှင့် များများပြောနေမိပြန်သည်။ ထို့ကြောင့် ကျွန်ုပ်သည် ကျွန်ုပ်ထင်တာထက် ပိုညံ့ကြောင်း ပြဆိုနေလေသည်။ ထို့ကြောင့် ကျွန်ုပ် အခုအိပ်ပြီ။

စာကြွင်း :: ပညာတစ်ခုအား ဟပ်ချလောင်းဆိုတာနဲ့ ချက်ခြင်းမကျလာကြောင်းကို ကျွန်ုပ်မျက်ဝါးထင်ထင် ကြုံတွေ့ခဲ့ရလေသည်။

oAuth နဲ့ AuthSub ကြားမှာ မူးသွားတာပဲ။ AuthSub နဲ့တော့ ရပြီ။ oAuth က နောက်တော့မှ twitter နဲ့စမ်းရမယ်။ google က အပြည့်အဝ support မပေးဘူး။ example တွေက AuthSub တွေနဲ့ ကြီးပဲဆိုတော့။ အခု code တောင် မနည်းမနည်းပဲ။ နောက်ဆုံးတော့ http://www.alexc.me/using-the-google-analytics-api-getting-total-number-of-page-views/74/#step2 အဲဒီကနေ တွေ့သွားလို့ အဆင်ပြေသွားတာ။ token ရပြီးရင် token ထပ်ယူရမှာကို မသိလိုက်တာ ဆိုးသွားတာ။

<?php

function make_api_call($url, $token)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$curlheader[0] = sprintf("Authorization: AuthSub token=\"%s\"/n", $token);
curl_setopt($ch, CURLOPT_HTTPHEADER, $curlheader);
$output = curl_exec($ch);
curl_close($ch);
return $output;
}

function get_session_token($onetimetoken) {
$output = make_api_call("https://www.google.com/accounts/AuthSubSessionToken", $onetimetoken);

if (preg_match("/Token=(.*)/", $output, $matches))
{
$sessiontoken = $matches[1];
} else {
echo "Error authenticating with Google.";
exit;
}
return $sessiontoken;
}

if(isset($_GET['token']))
{
$sessiontoken=get_session_token($_GET['token']);
$accountxml = make_api_call("http://www.google.com/m8/feeds/contacts/yourmail@gmail.com/full", $sessiontoken);
print_r($accountxml);

}
else
{
$next=urlencode("http://www.mysteryzillion.org/gdata/index.php");
$scope=urlencode("http://www.google.com/m8/feeds/contacts/yourmail@gmail.com/full");
?>
<a href="https://www.google.com/accounts/AuthSubRequest?next=<?= $next ?>&scope=<?= $scope ?>&secure=0&session=1">Click here to authenticate through Google.</a>

<?
}
?>

အခုတလော WordPress , Drupal , Google Apps API တွေနဲ့ ပဲ ရှုပ်နေတာပဲ။

WordPress

wordpress ကတော့ ပြဿနာမရှိဘူး။ ဒါပေမယ့် လုပ်လိုက်တော့ ပိုသဘောကျပြီး ပိုလုပ်တတ်သွားတယ်။ wordpress customization တစ်ခုလုံးက template ကစားသွားတာပဲ။လိုအပ်တဲ့ plugins တွေ ထပ်ရေးနေတာထက် template လေး တစ်ခုဆောက်တာက ပိုပြီး ထိရောက်မြန်ဆန်တယ်။ template လေးကစားသွားလိုက်ရုံနဲ့ တော်တော်လေးကို ထိထိရောက်ရောက် ဖြစ်သွားတာပဲ။ wordpress မှာလည်း သူ့ function တွေ ခေါ်ယူပြီးတော့ စိတ်ကြိုက်ပြုပြင်လို့ရတာတော့ တော်တော်မိုက်တယ်။ function တွေလည်း ပြည့်ပြည့်စုံစုံပေးထားတော့ အဆင်ပြေတယ်။ ဟိုတစ်ခါက MZ မှာ emo မေးထားဘူးတယ်။ wordpress က page နောက်တစ်ခုအတွက် template ပုံစံပြောင်းလို့မရဘူးတဲ့။ အဲဒါတော့ ဟုတ်ပါတယ်။ ဟုတ်လည်း မဟုတ်ပြန်ဘူး။ ကိုယ့်ဘာသာကိုယ် template page တစ်ခု ထပ်ဖြည့်လိုက်ပြီး လိုအပ်တဲ့ ပုံစံပြောင်းလို့ရတယ်။ ကိုယ်လိုချင်တဲ့ file တွေကိုလည်း include တွေနဲ့ ထပ်ဖြည့်လိုက်ပြီး လိုသလို ပြောင်းလို့ရပါတယ်။ ရေးရတာလည်း မခက်ပါဘူး။

<?php
/*
Template Name: Snarfer
*/
?>

ဆိုရင် template တစ်ခုဖြစ်သွားပြီး ကိုယ်လိုသလို page မှာ ခေါ်ပြီး ပြောင်းလဲရေးလို့ရပါတယ်။ codex မှာ အပြည့်အစုံ ရှိပါတယ်။ WordPress ကိုတော့ အရင် ကတည်းက crazy ဆိုတော့ wordpress ပိုင်းလုပ်ရတာ သိပ်ခက်ခဲလှတယ်မဟုတ်ဘူး။ အားရင်တော့ plugins လေးတစ်ခု ထပ်စမ်းရေးကြည့်အုံးမယ်။ admin panel setting ပါတဲ့ plugins မရေးဘူးသေးဘူးဆိုတော့ အဲဒါလေး စမ်းကြည့်မယ်။ ဘယ်လိုရေးရမလဲဆိုတာ စာတွေ့ပဲရှိတယ်။ အခြား admin panel setting မပါတာတွေတော့ ရေးဘူးတယ်။

Drupal
အရင်ကတည်းက မကြိုက်။ အခုတော့ ပိုဆိုးပေါ့။ Drupal အစစ်ကြီးဆိုလည်းထားလိုက်။ အခုက သူက ကျွန်တော်တို့wordpress မှာ လုပ်သလို template ကစားထားတာကို ပြန်ပြင်နေရတာ။ လုပ်သွားတဲ့သူက Drupal ကို တော်တော်လေး ကျွမ်းကျင်တယ်။ Admin Panel တစ်ခုလုံးလည်း ပြောင်းချသွားတယ်။ ကိုယ်ပိုင် module တွေလည်း ထပ်ဖြည့်သွားတော့ ဘယ်ဟာကို ဘယ်မှာ ပြင်ရမှန်းမသိပဲ ဖြစ်ကုန်ရော။ online မှာလည်း ရှာမရနဲ့။ ဒီလိုပဲ စမ်းတဝါးဝါးနဲ့ လုပ်ရင်း တော်တော်အဆင်ပြေလာတာပဲ။ Drupal လည်း တော်တော်ကောင်းတယ်။ သူ့ကို ကျွမ်းကျင်ရင် တော်တော်လေးကို လုပ်လို့ရတာပဲ။ စိတ်ကြိုက် ဖန်တီးလို့ရတယ်။ သူလည်း wordpress လိုမျိုးပဲ။ သူက wordpress ထက်သာတဲ့ အပိုင်းတွေ အများကြီးပဲ။ သူက ကောင်းပေမယ့် ရှုပ်လွန်းတယ်။ function တွေ များတော့ GUI လည်း ရှုပ်ကုန်ကော။ သူ့ရဲ့ သဘောတရားနားမလည်လို့လား မသိဘူး။ သူက နည်းနည်းရှုပ်ထွေးတယ်။ CMS သဘောတရားကို အပြည့်အဝသုံးထားပြီး block တွေဘာတွေနဲ့ စနစ်တကျတော့ ရှိတယ်။ wordpress က CMS လုံးလုံးကို မဟုတ်ပေမယ့် လုပ်ကြံပြီး အမြင်မှာ CMS ထင်အောင် တော့ ဖန်တီးနိုင်တယ်လေ။

Google Apps API
ခေါင်းအစားဆုံး အပိုင်းပဲ။ Zend အတွက်ပဲ support ရှိတယ်။ Zend framework မသုံးပဲ Zend Library အပြည့်အဝ သုံးလိုက်ရင်တော့ ရတယ်။ ဒါပေမယ့် Domain share contact က .NET အတွက်ရှိတယ်။ python အတွက်ရှိတယ်။ PHP Native အတွက် မရှိပြန်ဘူး။ Protocol သုံးရင်တော့ အကောင်းဆုံးဆိုပြီး သုံးဖို့လုပ်ပြန်ကော။ oAuth , AuthSub တွေကတော့ PHP Native နဲ့ အဆင်မပြေပြန်ဘူး။ oAuth က သီးသန့် ထပ်သွင်းရအုံးမယ်။ oAuth သွင်းဖို့အတွက်ကလည်း အထက်ကို report လုပ်ရအုံးမယ်။ ဒါတောင် စမ်းဖို့။ အချိန်ကလည်း သိပ်မရတော့ နောက်ဆုံး python ကို background ထားပြီး PHP နဲ့ front end လုပ်ပလိုက်တယ်။ Domain share contact ကလည်း 24 hours ကြာတယ်။ contact ထဲကို ဝင်ဖို့ အဲလောက်တောင် စောင့်ရတယ်။ လူတွေကလည်း သိတဲ့အတိုင်း အခုထည့် အခုမြင်လိုချင်ကြတာ။ ဒါပေမယ့် domain share contact က မရတော့လည်း ဘယ်တတ်နိုင်မလဲ။ export ကလည်း တစ်ခါတစ်လေ မထွက်။

Google Map API လုပ်ထားတာတော်တော်ကောင်းသလောက် google apps api လုပ်ထားတာကို သိပ်သဘောမကျဘူး။ လူအသုံးများတာကို support မလုပ်ပဲ အဆင့်တွေ အများကြီးနဲ့ ရှုပ်နေတယ်လို့ ထင်တာပဲ။ facebook connect လိုမျိုး api ဆိုလည်း တော်တော်လေးကောင်းတယ်။ ရိုးတယ်။ ရှင်းတယ်။ လွယ်တယ်။ Google Apps Engine ကတော့ java နဲ့ python ပဲ။ Google Apps အဖွဲ့တစ်ခုလုံးက အဓိက python ပဲ သုံးတယ်ထင်တယ်။ PHP ပိုင်းကို သီးသန့် library မထုတ်ပေးဘူး။ Zend နဲ့ တွဲထုတ်ပေးတော့ ဆင်ဖိုးထက် ချွန်းဖိုးက ပိုဆိုးဖြစ်နေတာပေါ့။ လုပ်ချင်တာက သေးသေးလေး။ အဲဒီအတွက် Zend Framework ကြီးပါ upload တင်ရတာ အလကား အလုပ်ရှုပ်တာပဲ။

ဘာပဲပြောပြော oAuth, AuthSub တွေတော့ ဖတ်ဖြစ်လိုက်တယ်။ လက်တွေ့တော့ အခုထက်ထိ စမ်းတာ အဆင်မပြေသေးဘူး။