JSON-RPC လား။ လှည့်စားအနားယူပါ။

ခေါင်းစီးက ကျန်းမာရေးနဲ့ညီညွတ်တဲ့ တုံ့ပြန်မှုကို ဖြစ်စေတာ သေချာပါတယ် - "ကောင်းပြီ၊ အဲဒါ ပြန်စပြီ..." ဒါပေမယ့် မင်းရဲ့အာရုံကို 5-10 မိနစ်လောက်ကြာအောင် ဖမ်းထားပါရစေ၊ မင်းရဲ့မျှော်လင့်ချက်တွေကို စိတ်ပျက်ဖို့ ငါကြိုးစားမယ်။

ဆောင်းပါး၏ဖွဲ့စည်းပုံမှာ အောက်ပါအတိုင်းဖြစ်လိမ့်မည်- ဒီပွဲမှာ ထုတ်ပြန်ချက်တစ်ခုကို ယူဆောင်ပြီး ဤပုံသေပုံစံ ပေါ်ပေါက်လာခြင်း၏ “သဘောသဘာဝ” ကို ထုတ်ဖော်ခဲ့သည်။ ၎င်းသည် သင့်ပရောဂျက်များတွင် ဒေတာဖလှယ်မှုဆိုင်ရာ ပါရာဒိုင်းရွေးချယ်မှုကို ရှုထောင့်အသစ်မှ ကြည့်ရှုနိုင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်။

RPC ဆိုတာ ဘာလဲဆိုတာကို ရှင်းရှင်းလင်းလင်း သိနိုင်ဖို့ စံနှုန်းကို စဉ်းစားဖို့ အဆိုပြုပါတယ်။ JSON-RPC 2.0. REST ဖြင့် ရှင်းလင်းမှု မရှိပါ။ မဖြစ်သင့်ဘူး။ REST အကြောင်း သိလိုသမျှ - ၎င်းနှင့် ခွဲခြား၍မရပါ။ သည် HTTP.

RPC တောင်းဆိုမှုများသည် သင့်အား အစုလိုက်တောင်းဆိုမှုများကို ပြုလုပ်နိုင်စေသောကြောင့် ၎င်းတို့သည် ပိုမိုမြန်ဆန်ပြီး ပိုမိုထိရောက်ပါသည်။

အဓိကအချက်မှာ RPC တွင် သင်သည် တောင်းဆိုချက်တစ်ခုတည်းတွင် လုပ်ထုံးလုပ်နည်းများစွာကို တစ်ကြိမ်တည်းခေါ်ဆိုနိုင်သည်။ ဥပမာအားဖြင့်၊ အသုံးပြုသူတစ်ဦးဖန်တီးပါ၊ သူ့ထံကိုယ်ပွားတစ်ခုထည့်ပါ၊ တူညီသောတောင်းဆိုချက်တွင်၊ အချို့သောအကြောင်းအရာများတွင် သူ့ကိုစာရင်းသွင်းပါ။ တောင်းဆိုချက်တစ်ခုပဲ၊ ဘယ်လောက်အကျိုးရှိလဲ။

အမှန်မှာ၊ သင့်တွင် backend node တစ်ခုသာရှိပါက၊ batch တောင်းဆိုမှုဖြင့် ၎င်းသည် ပိုမိုမြန်ဆန်လာမည်ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် REST တောင်းဆိုချက်သုံးခုသည် ချိတ်ဆက်မှုများကို တည်ဆောက်ရန်အတွက် node တစ်ခုမှ အရင်းအမြစ်များ သုံးဆပိုမိုလိုအပ်မည်ဖြစ်သည်။

REST ကိစ္စတွင် ပထမတောင်းဆိုချက်သည် နောက်ဆက်တွဲတောင်းဆိုမှုများပြုလုပ်ရန်အတွက် အသုံးပြုသူ ID ကို ပြန်ပေးရမည်ဖြစ်ကြောင်း သတိပြုပါ။ ၎င်းသည် အလုံးစုံရလဒ်ကို ထိခိုက်စေပါသည်။

သို့သော် ထိုကဲ့သို့သော အခြေခံအဆောက်အအုံများကို အိမ်တွင်းဖြေရှင်းချက်များနှင့် လုပ်ငန်းများတွင်သာ တွေ့ရှိနိုင်သည်။ WEB ပရောဂျက်ငယ်များတွင် နောက်ဆုံးအားကိုးရာတစ်ခုဖြစ်သည်။ သို့သော် ပြီးပြည့်စုံသော WEB ဖြေရှင်းချက်များနှင့် HighLoad ဟုခေါ်သည့်တောင်မှ တည်ဆောက်ရန်မထိုက်တန်ပါ။ ၎င်းတို့၏ အခြေခံအဆောက်အအုံများသည် မြင့်မားသောရရှိနိုင်မှုနှင့် ဝန်ဆောင်မှုဆိုင်ရာ သတ်မှတ်ချက်များနှင့် ပြည့်မီရမည်ဖြစ်သည်။ ပြီးတော့ ပုံက ပြောင်းနေတယ်။

တူညီသောအခြေအနေအောက်တွင် အခြေခံအဆောက်အအုံဆိုင်ရာ လှုပ်ရှားမှုချန်နယ်များကို အစိမ်းရောင်ဖြင့် အမှတ်အသားပြုထားသည်။ RPC မည်ကဲ့သို့ ပြုမူသည်ကို သတိပြုပါ။ တောင်းဆိုချက်သည် ချိန်ခွင်လျှာမှ နောက်ကွယ်သို့ ခြေထောက်တစ်ဖက်တည်းတွင် အခြေခံအဆောက်အအုံကို အသုံးပြုသည်။ ပထမတောင်းဆိုချက်တွင် REST ရှုံးနေသော်လည်း အခြေခံအဆောက်အအုံတစ်ခုလုံးကို အသုံးပြု၍ ဆုံးရှုံးသွားသောအချိန်အတွက် ဖန်တီးပေးသည်။

ဇာတ်ညွှန်းထဲသို့ ဖြည့်သွင်းရန် လုံလောက်သော တောင်းဆိုချက် နှစ်ခုမဟုတ်သော်လည်း၊ ငါးခု သို့မဟုတ် ဆယ်ခုကို ပြောပါ... နှင့် "အခု ဘယ်သူအနိုင်ရမလဲ" ဆိုတဲ့ မေးခွန်းရဲ့ အဖြေပါ။ မရှင်းမလင်းဖြစ်လာသည်။

ပြဿနာကို ပိုမိုကျယ်ပြန့်စွာ ရှုမြင်ရန် အဆိုပြုပါသည်။ ပုံကြမ်းတွင် အခြေခံအဆောက်အအုံချန်နယ်များကို မည်သို့အသုံးပြုကြောင်းပြသသော်လည်း အခြေခံအဆောက်အအုံသည် ချန်နယ်များအတွက် အကန့်အသတ်မရှိပါ။ ဝန်အားမြင့်မားသော အခြေခံအဆောက်အအုံ၏ အရေးကြီးသော အစိတ်အပိုင်းမှာ ကက်ရှ်များဖြစ်သည်။ ယခု အသုံးပြုသူ အတုအယောင် တစ်မျိုးကို ရယူလိုက်ရအောင်။ အကြိမ်ကြိမ်။ ၃၂ ကြိမ်ဆိုပါစို့။

မြင့်မားသောဝန်လိုအပ်ချက်များကိုဖြည့်ဆည်းရန် RPC အခြေခံအဆောက်အအုံသည် သိသိသာသာတိုးတက်ကောင်းမွန်လာပုံကိုကြည့်ပါ။ အကြောင်းမှာ REST သည် RPC နှင့်မတူဘဲ HTTP ပရိုတိုကော၏ ပါဝါအပြည့်ကို အသုံးပြုထားသည်။ အထက်ဖော်ပြပါ ပုံတွင် ဤပါဝါအား တောင်းဆိုမှုနည်းလမ်း - GET ဖြင့် နားလည်သည်။

HTTP နည်းလမ်းများ၊ အခြားအရာများထဲတွင် ကက်ချခြင်းဗျူဟာများရှိသည်။ ၎င်းတို့ကို စာရွက်စာတမ်းများတွင် ရှာဖွေနိုင်ပါသည်။ သည် HTTP. RPC အတွက်၊ POST တောင်းဆိုမှုများကို အစွမ်းထက်မြက်သည်ဟု ယူဆခြင်းမရှိသည့်၊ ဆိုလိုသည်မှာ တူညီသော POST တောင်းဆိုမှုများ၏ ထပ်ခါတလဲလဲ ထပ်ခါတလဲလဲ တောင်းဆိုမှုများသည် မတူညီသော ရလဒ်များ ပြန်လာနိုင်သည် (ဥပမာ၊ မှတ်ချက်တစ်ခုစီကို ပေးပို့ပြီးနောက်၊ ဤမှတ်ချက်၏ အခြားမိတ္တူပေါ်လာမည်) (အရင်းအမြစ်).

ထို့ကြောင့် RPC သည် အခြေခံအဆောက်အဦ caches ကို ထိထိရောက်ရောက် အသုံးမပြုနိုင်ပါ။ ၎င်းသည် ဆော့ဖ်ဝဲလ် ကက်ရှ်များကို တင်သွင်းရန် လိုအပ်သည်။ ပုံကြမ်းသည် ဤအခန်းကဏ္ဍတွင် Redis ကိုပြသသည်။ ဆော့ဖ်ဝဲလ် ကက်ရှ်သည် တစ်ဖန်၊ ဖန်တီးသူအား ကုဒ်အလွှာတစ်ခု ထပ်ထည့်ရန်နှင့် ဗိသုကာလက်ရာတွင် သိသာထင်ရှားသော အပြောင်းအလဲများကို ထည့်သွင်းရန် လိုအပ်သည်။

ထည့်သွင်းစဉ်းစားနေသော အခြေခံအဆောက်အဦတွင် REST နှင့် RPC "မွေးဖွားပေး" တောင်းဆိုမှု မည်မျှရှိသည်ကို ယခုရေတွက်ကြည့်ကြပါစို့။

တောင်းဆိုချက်များ
စာပုံး
backend လုပ်ဖို့
DBMS သို့
soft cache ( Redis ) သို့
စုစုပေါင်း

REST
1 / 32 *
1
1
0
3 / 35

CPR
32
32
1
31
96

[*] အကောင်းဆုံးအခြေအနေတွင် (ဒေသခံ cache ကိုအသုံးပြုပါက) တောင်းဆိုချက် 1 ခု (တစ်ခု!)၊ အဆိုးဆုံးအခြေအနေတွင် ဝင်လာသော တောင်းဆိုချက် 32 ခု။

ပထမအစီအစဥ်နဲ့ ယှဉ်ရင် ကွာခြားချက်က သိသိသာသာပါပဲ။ အခုတော့ REST ရဲ့ အကျိုးကျေးဇူးက ရှင်းသွားပါပြီ။ ဒါပေမယ့် အဲ့ဒီမှာ ရပ်မနေဖို့ အကြံပြုချင်ပါတယ်။ ဖွံ့ဖြိုးပြီးသော အခြေခံအဆောက်အအုံများတွင် CDN ပါဝင်သည်။ မကြာခဏဆိုသလို DDoS နှင့် DoS တိုက်ခိုက်မှုများကို တန်ပြန်သည့်ပြဿနာကိုလည်း ဖြေရှင်းပေးသည်။ ကျွန်ုပ်တို့ရရှိသည်-

ဒါက RPC အတွက် တကယ်ကို ဆိုးရွားတဲ့ နေရာပါ။ RPC သည် အလုပ်တာဝန်အား CDN ​​သို့ လွှဲအပ်ပေးနိုင်စွမ်းမရှိပါ။ တန်ပြန်တိုက်ခိုက်မှုများအတွက် စနစ်များကိုသာ ကျွန်ုပ်တို့အားကိုးနိုင်ပါသည်။

ဤနေရာတွင် အဆုံးသတ်ရန် ဖြစ်နိုင်ပါသလား။ နောက်တဖန်၊ အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း HTTP နည်းလမ်းများတွင် ၎င်းတို့၏ ကိုယ်ပိုင် “မှော်ပညာ” ရှိသည်။ GET နည်းလမ်းကို အင်တာနက်မှာ တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေတာကြောင့် အကြောင်းပြချက်မရှိဘဲ မဟုတ်ပါဘူး။ ဤနည်းလမ်းသည် အကြောင်းအရာတစ်ခုအား ဝင်ရောက်ကြည့်ရှုနိုင်သည်၊ ထိန်းချုပ်မှုမှ သင့်ကုဒ်သို့မလွှဲပြောင်းမီ အခြေခံအဆောက်အအုံအစိတ်အပိုင်းများကို အဓိပ္ပာယ်ဖွင့်ဆိုနိုင်သည့် အခြေအနေများကို သတ်မှတ်ပေးနိုင်သည် စသည်တို့ကို သတိပြုပါ။ ဤအရာအားလုံးသည် အမှန်တကယ်ကြီးမားသော တောင်းဆိုမှုများကို ကိုင်တွယ်နိုင်သည့် ပြောင်းလွယ်ပြင်လွယ်၊ စီမံခန့်ခွဲနိုင်သော အခြေခံအဆောက်အအုံများကို ဖန်တီးနိုင်စေမည်ဖြစ်သည်။ သို့သော် RPC တွင် ဤနည်းလမ်းကို လျစ်လျူရှုထားသည်။

ဒါဆို batch Requests (RPC) က ဘာကြောင့် ဒီထက်ပိုမြန်ရတာလဲ။ ပုဂ္ဂိုလ်ရေးအရ၊ ပရောဂျက်အများစုသည် REST ၏ အစွမ်းသတ္တိကို ပြသနိုင်သည့် ဖွံ့ဖြိုးတိုးတက်မှုအဆင့်သို့ မရောက်နိုင်ဟု ကျွန်ုပ်ထင်ပါသည်။ ထို့အပြင် အသေးစား ပရောဂျက်များတွင်လည်း သူ၏ အားနည်းချက်များကို ပြသလိုစိတ် ပိုများသည်။

REST သို့မဟုတ် RPC ရွေးချယ်မှုသည် ပရောဂျက်တစ်ခုရှိ တစ်ဦးချင်းစီ၏ ဆန္ဒအလျောက် ရွေးချယ်မှုမဟုတ်ပါ။ ဤရွေးချယ်မှုသည် ပရောဂျက်၏ လိုအပ်ချက်များနှင့် ကိုက်ညီရမည်။ အကယ်၍ ပရောဂျက်တစ်ခုသည် REST မှ အမှန်တကယ်လိုအပ်သမျှကို ညှစ်ထုတ်နိုင်လျှင် REST သည် အကောင်းဆုံးရွေးချယ်မှုတစ်ခုဖြစ်သည်။

အကယ်၍ REST ၏ အကျိုးကျေးဇူးအားလုံးကို ရရန်အတွက် အကယ်၍ သင်သည် အခြေခံအဆောက်အအုံကို လျင်မြန်စွာ တိုင်းတာရန်၊ အခြေခံအဆောက်အအုံကို စီမံခန့်ခွဲရန် စီမံခန့်ခွဲသူများ၊ WEB ဝန်ဆောင်မှု၏ အလွှာအားလုံးကို ဒီဇိုင်းထုတ်ရန် ဗိသုကာပညာရှင်တစ်ဦးကို ငှားရမ်းရန် လိုအပ်ပါသည်။ တစ်ချိန်တည်းမှာပဲ တစ်နေ့ကို မာဂျရင်း ၃ ထုပ်ရောင်းတယ်... ငါ RPC နဲ့ ကပ်နေတာမို့... ဤပရိုတိုကောသည် ပိုမိုအကျိုးရှိစေပါသည်။ ၎င်းသည် ကက်ရှ်များနှင့် အခြေခံအဆောက်အဦများ မည်သို့အလုပ်လုပ်ကြောင်း နက်နဲသောအသိပညာမလိုအပ်သော်လည်း၊ ဆော့ဖ်ဝဲရေးသားသူအား သူလိုအပ်သောလုပ်ထုံးလုပ်နည်းများအတွက် ရိုးရှင်းပြီး နားလည်နိုင်သောခေါ်ဆိုမှုများကို အာရုံစိုက်မည်ဖြစ်သည်။ စီးပွား​ရေး ​ပျော်​ရွှင်​​နေမည်​။

RPC တောင်းဆိုမှုများသည် ငွေပေးငွေယူတစ်ခုတည်းအတွင်း batch တောင်းဆိုမှုများကို လုပ်ဆောင်နိုင်သောကြောင့် ပိုမိုယုံကြည်စိတ်ချရသည်။

RPC ၏ ဤပိုင်ဆိုင်မှုသည် တိကျသေချာသော အားသာချက်ဖြစ်သောကြောင့် ဖြစ်သည်။ ဒေတာဘေ့စ်ကို တသမတ်တည်းထားရန် လွယ်ကူသည်။ ဒါပေမယ့် REST နဲ့ဆိုရင် ပိုပိုပြီး ရှုပ်ထွေးလာပါတယ်။ တောင်းဆိုချက်များသည် မတူညီသော backend node များဆီသို့ တသမတ်တည်း ရောက်သွားနိုင်သည်။

REST ၏ ဤ "အားနည်းချက်" သည် အထက်တွင်ဖော်ပြထားသော ၎င်း၏အားသာချက်၏ နောက်ပြန်အခြမ်းဖြစ်သည် - အခြေခံအဆောက်အဦအရင်းအမြစ်အားလုံးကို ထိထိရောက်ရောက်အသုံးပြုနိုင်မှု။ အကယ်၍ အခြေခံအဆောက်အဦများ ညံ့ဖျင်းပါက၊ ပရောဂျက်၏ ဗိသုကာလက်ရာများနှင့် အထူးသဖြင့် ဒေတာဘေ့စ်ကို ဒီဇိုင်းရေးဆွဲမှု ညံ့ဖျင်းပါက၊ ယင်းသည် အမှန်တကယ်ပင် နာကျင်စရာကြီးဖြစ်သည်။

သို့သော် အစုလိုက်တောင်းဆိုမှုများသည် ၎င်းတို့ထင်သလောက် စိတ်ချရပါသလား။ ကိစ္စတစ်ခုကို ကြည့်ကြပါစို့။ ကျွန်ုပ်တို့သည် သုံးစွဲသူတစ်ဦးကို ဖန်တီးပြီး ၎င်း၏ပရိုဖိုင်ကို ဖော်ပြချက်အချို့ဖြင့် ဖြည့်သွင်းပြီး မှတ်ပုံတင်ပြီးမြောက်ရန် လျှို့ဝှက်ချက်တစ်ခုဖြင့် သူ့ကို SMS တစ်စောင် ပေးပို့ပါ။ အဲဒါတွေ။ batch တစ်ခုတွင် တောင်းဆိုမှုသုံးကြိမ်။

ပုံကြမ်းကို ကြည့်ရအောင်။ မြင့်မားသောရရှိနိုင်မှုဒြပ်စင်များပါ ၀ င်သောအခြေခံအဆောက်အအုံကိုတင်ပြသည်။ SMS gateways နှင့် သီးခြားလွတ်လပ်သော ဆက်သွယ်ရေးလမ်းကြောင်းနှစ်ခုရှိသည်။ ဒါပေမယ့်... ငါတို့ ဘာမြင်လဲ။ SMS ပေးပို့သည့်အခါ အမှားအယွင်း 503 ဖြစ်ပေါ်သည် - ဝန်ဆောင်မှုကို ခေတ္တမရနိုင်ပါ။ ဘာဖြစ်လို့လဲဆိုတော့ SMS ပေးပို့ခြင်းကို အစုလိုက်တောင်းဆိုမှုတစ်ခုတွင် ထုပ်ပိုးထားပြီး၊ ထို့နောက် တောင်းဆိုချက်တစ်ခုလုံးကို ပြန်လည်ရုပ်သိမ်းရမည်ဖြစ်သည်။ DBMS တွင် လုပ်ဆောင်ချက်များကို ပယ်ဖျက်ထားသည်။ client သည် အမှားအယွင်းတစ်ခုကို လက်ခံရရှိသည် ။

နောက်တစ်ခုကတော့ ကံစမ်းမဲပါ။ တောင်းဆိုချက်သည် တူညီသော node ကို ထပ်ခါတလဲလဲ အမှားတစ်ခုပြန်ပို့မည် သို့မဟုတ် သင်ကံကောင်းမည်ဖြစ်ပြီး ၎င်းကို လုပ်ဆောင်မည်ဖြစ်သည်။ သို့သော် အဓိကအချက်မှာ ကျွန်ုပ်တို့၏အခြေခံအဆောက်အအုံသည် အနည်းဆုံးတစ်ကြိမ် အချည်းနှီးဖြစ်နေပြီဖြစ်သည်။ ဝန်ရှိသော်လည်း အကျိုးမရှိပေ။

ကောင်းပြီ၊ ကျွန်ုပ်တို့သည် မိမိကိုယ်ကို (!) တင်းကျပ်ပြီး တောင်းဆိုမှု တစ်စိတ်တစ်ပိုင်း အောင်မြင်စွာ ပြီးမြောက်နိုင်သည့်အခါ ရွေးချယ်မှုကို စဉ်းစားကြည့်ကြပါစို့။ အချိန်အတိုင်းအတာတစ်ခုကြာပြီးနောက် ကျန်တာတွေကို ထပ်ပြီး ပြီးအောင်ကြိုးစားပါ့မယ် (ဘယ်ဟာက ရှေ့ဆုံးက ဆုံးဖြတ်မှာလဲ။) ဒါပေမယ့် ကံစမ်းမဲကတော့ ဒီအတိုင်းပါပဲ။ SMS ပေးပို့ရန် တောင်းဆိုမှုသည် ပျက်ကွက်နိုင်ခြေ 50/50 ရှိသည်။

သဘောတူပါသည်၊ ဖောက်သည်ဖက်မှ၊ ဝန်ဆောင်မှုသည် ကျွန်ုပ်တို့လိုချင်သလောက် စိတ်ချရပုံမပေါ်... REST ကော။

REST သည် HTTP ၏ ပဉ္စလက်ကို ထပ်မံအသုံးပြုသော်လည်း ယခုအခါ တုံ့ပြန်ကုဒ်များဖြင့် ပြုလုပ်ထားသည်။ SMS ဂိတ်ဝတွင် အမှားအယွင်း 503 ဖြစ်ပေါ်လာသောအခါ၊ နောက်ကွယ်မှသည် ဤအမှားကို ဟန်ချက်ညီစေရန် ထုတ်လွှင့်သည်။ Balancer သည် ဤအမှားကို လက်ခံရရှိပြီး client နှင့် ချိတ်ဆက်မှုကို မချိုးဖျက်ဘဲ တောင်းဆိုချက်ကို အောင်မြင်စွာ လုပ်ဆောင်နိုင်သည့် အခြား node သို့ တောင်းဆိုချက်ကို ပေးပို့ပါသည်။ အဲဒါတွေ။ ဖောက်သည်သည် မျှော်လင့်ထားသည့်ရလဒ်ကို လက်ခံရရှိပြီး အခြေခံအဆောက်အအုံသည် ၎င်း၏မြင့်မားသော “အလွန်ဝင်ရောက်နိုင်သော” ခေါင်းစဉ်ကို အတည်ပြုသည်။ သုံးစွဲသူက ပျော်တယ်။

ဒါတွေအားလုံးမဟုတ်ပြန်ဘူး။ ချိန်ခွင်လျှာသည် 503 ၏ တုံ့ပြန်မှုကုဒ်ကို လက်ခံရရှိရုံမျှမကဘဲ၊ စံနှုန်းအတိုင်း တုံ့ပြန်သည့်အခါ၊ ဤကုဒ်ကို “ပြန်လည်ကြိုးစားပြီးနောက်တွင်” ခေါင်းစီးဖြင့် ပေးဆောင်ရန် အကြံပြုလိုပါသည်။ သတ်မှတ်ထားသောအချိန်တစ်ခုအထိ ဤလမ်းကြောင်းရှိ ဤ node ကို မနှောင့်ယှက်သင့်ကြောင်း ချိန်ခွင်လျှာအား ခေါင်းစီးက ရှင်းလင်းစေသည်။ SMS ပေးပို့ရန် နောက်ထပ်တောင်းဆိုမှုများကို SMS gateway နှင့် ပြဿနာမရှိသော node သို့ တိုက်ရိုက်ပေးပို့မည်ဖြစ်ပါသည်။

ကျွန်ုပ်တို့မြင်ရသည့်အတိုင်း JSON-RPC ၏ယုံကြည်စိတ်ချရမှုသည် အဆင့်သတ်မှတ်မှုလွန်ကဲသည်။ တကယ်တော့၊ ဒေတာဘေ့စ်မှာ ညီညွတ်မှုကို စုစည်းဖို့ ပိုလွယ်ပါတယ်။ သို့သော် ဤကိစ္စတွင် စွန့်လွှတ်အနစ်နာခံမှုသည် စနစ်တစ်ခုလုံး၏ ယုံကြည်စိတ်ချရမှုဖြစ်လိမ့်မည်။

နိဂုံးချုပ်ချက်သည် ယခင်နှင့် အလွန်တူသည်။ အခြေခံအဆောက်အအုံသည် ရိုးရှင်းသောအခါ၊ JSON-RPC ၏ သိသာထင်ရှားမှုသည် အပေါင်းလက္ခဏာတစ်ခုဖြစ်သည်။ ပရောဂျက်တွင် ဝန်ထုပ်ဝန်ပိုး မြင့်မားစွာ ရရှိနိုင်မှု မြင့်မားပါက REST သည် ပို၍ ရှုပ်ထွေးသော်လည်း ဖြေရှင်းချက် ပိုမှန်ပုံရသည်။

REST သို့ ဝင်ရောက်မှုအဆင့်သည် နိမ့်ပါသည်။

အထက်ဖော်ပြပါ ခွဲခြမ်းစိတ်ဖြာချက်သည် RPC နှင့်ပတ်သက်သော ချမှတ်ထားသော စံနမူနာများကို ဖယ်ရှားခြင်းဖြင့် REST သို့ ဝင်ရောက်ရန် သတ်မှတ်ချက်သည် RPC ထက် သံသယမကင်းဖွယ်ရာ မြင့်မားကြောင်း ရှင်းရှင်းလင်းလင်း ပြသခဲ့သည်ဟု ကျွန်တော်ထင်ပါတယ်။ ၎င်းသည် HTTP အလုပ်လုပ်ပုံကို နက်နဲစွာ နားလည်ရန် လိုအပ်သည့်အပြင် WEB ပရောဂျက်များတွင် အသုံးပြုနိုင်သည့် ရှိပြီးသား အခြေခံအဆောက်အအုံဆိုင်ရာ အစိတ်အပိုင်းများအကြောင်း လုံလောက်သော အသိပညာရှိရန် လိုအပ်ခြင်းကြောင့် ဖြစ်သည်။

Так почему многие думают, что REST попроще будет? Лично мое мнение заключается в том, что эта кажущаяся простота исходит из самих манифестов REST. Т.е. REST это не протокол, а концепция… у REST нет стандарта, есть некоторые рекомендации… REST не сложнее HTTP. Кажущаяся свобода и анархия манит “свободных художников”.

ဟုတ်ပါတယ်၊ REST က HTTP ထက် ပိုရှုပ်ထွေးတာမရှိပါဘူး။ သို့သော် HTTP ကိုယ်တိုင်က ဆယ်စုနှစ်များစွာ တန်ဖိုးရှိကြောင်း သက်သေပြခဲ့သည့် ကောင်းမွန်စွာ ဒီဇိုင်းဆွဲထားသော ပရိုတိုကောတစ်ခုဖြစ်သည်။ HTTP ကိုယ်တိုင်က နက်နက်နဲနဲ နားလည်မှုမရှိရင် REST ကို အကဲဖြတ်လို့ မရပါဘူး။

ဒါပေမယ့် RPC အကြောင်း - သင်လုပ်နိုင်တယ်။ ၎င်း၏သတ်မှတ်ချက်ကိုယူရန်လုံလောက်သည်။ ဒါဆို မင်းလိုအပ်လား။ မိုက်မဲသော JSON-RPC? ဒါမှမဟုတ် REST က ခက်နေသေးလား။ သင်ဆုံးဖြတ်။

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

source: www.habr.com