SockJS ပရောက်စီ မအောင်မြင်မှုသည် အရန်လမ်းကြောင်းပြီးမှသာ အဘယ်ကြောင့် ပေါ်လာနိုင်သနည်း
WebSocket လမ်းကြောင်းနှင့် XHR အရန်လမ်းကြောင်းသည် မတူညီသော HTTP ကလိုင်းများကို သုံးနိုင်သည်။ ပရောက်စီ ဆက်တင်များကို မပြောင်းမီ မအောင်မြင်သော သယ်ယူမှုကို ဖော်ထုတ်ပါ။
ကွန်ရက်တစ်ခုတွင် WebSocket အလုပ်လုပ်သော်လည်း အခြားတစ်ခုတွင် SockJS မအောင်မြင်ပါက ဒုတိယကွန်ရက်သည် XHR အရန်လမ်းကြောင်းကို စတင်ခဲ့နိုင်သည်။ ၎င်းသည် တောင်းဆိုချက်များကို လုပ်ဆောင်သော HTTP အကောင်အထည်ဖော်မှုကို ပြောင်းလဲနိုင်သည် — ထို့ကြောင့် အသုံးပြုနေသော ပရောက်စီ ဖွဲ့စည်းမှုကိုလည်း ပြောင်းလဲနိုင်သည်။
ပထမဆုံး မအောင်မြင်သော URL နှင့် ၎င်းရွေးချယ်သော သယ်ယူမှုကို ရှာပါ။ SockJS သည် သယ်ယူမှု မရွေးချယ်မီ HTTP အချက်အလက် တောင်းဆိုချက် ပြုလုပ်နိုင်သည်။ WebSocket လက်ဆွဲနှုတ်ဆက်မှုနှင့် နောက်ဆက်တွဲ စစ်တမ်းတောင်းဆိုချက်များသည် သီးခြား လုပ်ငန်းစဉ်များဖြစ်သည်။ အလုပ်လုပ်သော လက်ဆွဲနှုတ်ဆက်မှု ဖွဲ့စည်းမှုသည် ၎င်းတို့တစ်ခုစီအတွက် အသုံးပြုသော လမ်းကြောင်းကို သက်သေမပြပါ။
Spring ၏ Java ကလိုင်းတွင် RestTemplateXhrTransport သည် ဖွဲ့စည်းထားသော RestTemplate ကို လက်ခံသည်။ ၎င်း၏ တောင်းဆိုချက် စက်ရုံနှင့် အခြေခံ HTTP ကလိုင်းသည် အရန်လမ်းကြောင်း ပံ့ပိုးသော ပရောက်စီလမ်းကြောင်းနှင့် စစ်မှန်ကြောင်း အတည်ပြုမှုကို ပေးသည်။ HttpClient 5 ဖြင့် Spring 6 အတွက် ထို RestTemplate ၏ အမှန်တကယ် တောင်းဆိုချက် စက်ရုံကို ဖွဲ့စည်းပါ။ ထို အကောင်အထည်ဖော်မှုသည် Apache HTTP အစိတ်အပိုင်းများကို သုံးပါက ၎င်း၏ မျိုးဆက်သည် ပေါင်းစည်းမှုနှင့် ကိုက်ညီရမည်။
WebSocket ကလိုင်းတွင် ၎င်း၏ ကိုယ်ပိုင် မှတ်တမ်းတင်ထားသော ချိတ်ဆက်မှု ဆက်တင်များ ရှိသည်။ JVM ပရောက်စီ ဂုဏ်သတ္တိများသည် ၎င်း၏ တိကျသော ကလိုင်းက ဖတ်မှသာ လမ်းကြောင်းကို သက်ရောက်သည်။ အလုပ်လုပ်သော နှင့် မအောင်မြင်သော ပတ်ဝန်းကျင်များကို သယ်ယူမှု၊ ကလိုင်း အကောင်အထည်ဖော်မှု၊ ရွေးချယ်ထားသော ပရောက်စီနှင့် ပထမဆုံး အမှားဖြင့် နှိုင်းယှဉ်ပါ။ XHR သာ မအောင်မြင်ပါက အလုပ်လုပ်သော WebSocket ကလိုင်း၏ ဆက်တင်များကို ထပ်ခါတလဲလဲ မပြောင်းဘဲ ၎င်း၏ လမ်းကြောင်း၊ စစ်မှန်ကြောင်း အတည်ပြုမှုနှင့် ကြာရှည်ထိန်းထားသော တုံ့ပြန်မှုများကို လိုက်နာပါ။