ပို့ဆောင်ရေးပရောက်စီက စိတ်ကြိုက် API ခေါင်းစီးကို မည်သို့ကိုင်တွယ်သည်

API တစ်ခုသည် ၎င်း၏ဗားရှင်းကို API-Version ကဲ့သို့သော စိတ်ကြိုက်တောင်းဆိုမှုအကွက်တွင် သယ်ဆောင်နိုင်သည်။ သာမန်ပို့ဆောင်ရေးပရောက်စီသည် အမည်မသိဖြစ်ရုံဖြင့် ထိုအကွက်ကို စွန့်ပစ်သင့်သည်မဟုတ်ပါ။ HTTP သည် သတ်မှတ်ထားသော ခြွင်းချက် သို့မဟုတ် သတ်မှတ်ထားသောမူဝါဒ မကျင့်သုံးပါက အသိအမှတ်မပြုသောအကွက်များကို ပို့ဆောင်ရန် တောင်းဆိုသည်။

Connection အကွက်သည် ထိုခြွင်းချက်များထဲမှ တစ်ခုဖြစ်သည်။ ဤဥပမာတောင်းဆိုမှုများကို နှိုင်းယှဉ်ပါ-

API-Version: 2026-10
Connection: keep-alive

ဤနေရာတွင် API အကွက်သည် ဤချိတ်ဆက်မှုအတွက် ဒေသခံအဖြစ် သတ်မှတ်မထားပါ။ နောက်ဥပမာတွင် ပို့သူက ၎င်း၏အတိုင်းအတာကို အတိအလင်းပြောင်းလဲသည်-

API-Version: 2026-10
Connection: API-Version

ပို့ဆောင်ရေးပရောက်စီသည် မပို့ဆောင်မီ Connection အမည်ပေးထားသောအကွက်များကို ဖယ်ရှားသည်၊ ချိတ်ဆက်မှုနှင့်သက်ဆိုင်သော ညွှန်ကြားချက်များကို ကိုယ်တိုင်ဖယ်ရှား သို့မဟုတ် အစားထိုးသည်။ ထို့ကြောင့် မူလအရင်းအမြစ်အတွက် ရည်ရွယ်ထားသော အပလီကေးရှင်းခေါင်းစီးသည် ထို token စာရင်းတွင် မပါဝင်သင့်ပါ။

အကွက်ပြောင်းလဲသည့်နေရာကို ရှာပါ

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

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

သာမန် CONNECT လိုဏ်ခေါင်းအတွင်း အစွန်းမှအစွန်း HTTPS အတွက် ပရောက်စီသည် အတွင်းပိုင်း API အကွက်ကို ဖတ်၍ ရွေးချယ်ဖယ်ရှား၍ မရပါ။ ထိုအခါ ခေါင်းစီးစစ်ဆေးမှုသည် TLS အစွန်းများ သို့မဟုတ် အတိအလင်းယုံကြည်ရသော စစ်ဆေးရေးကြားခံထံတွင် ရှိသည်။