Http

फक्त HTTP च्या ऐवजी प्रत्येक पानासाठी एकच WebSocket का वापरू नये?
हा प्रश्न वारंवार का विचारला जातो हे मला समजतं. WebSocket उघडं राहतं, तुम्ही कोण आहात हे लक्षात ठेवतं, आणि सर्व्हरला तुम्ही पुन्हा पुन्हा विचारल्याशिवाय डेटा पाठवू देतं. मग एकच सतत चालू राहणारी पाईप उघडून काम भागत असताना आपण अजूनही एका पान लोडसाठी शेकडो वेगवेगळे HTTP रिक्वेस्ट का पाठवतो? खरं सांगायचं तर हा प्रश्न लोक समजतात त्यापेक्षा जास्त हुशार आहे — आणि उत्तर “कारण HTTP जास्त चांगलं आहे” असं नाही. ते यापेक्षा बरंच गुंतागुंतीचं आहे.
वेबसॉकेट्स म्हणजे काय आणि ते HTTP पेक्षा कसे वेगळे आहेत?
“रिअल-टाइम गोष्टींसाठी वेबसॉकेट्स वापरा” हे मी सतत ऐकत होतो, पण प्रत्यक्षात वायरवर काय घडतं हे कोणीच नीट सांगत नव्हतं. म्हणून मी RFC वाचलं, काही सर्व्हर्स तपासले आणि जे समजलं ते लिहून काढायचं ठरवलं — यात मला सर्वात जास्त गोंधळात टाकणारा भाग म्हणजे: वेबसॉकेट हा स्वतःचा एक स्वतंत्र प्रोटोकॉल आहे की HTTP वर केलेली एक चलाख युक्ती? तर वेबसॉकेट म्हणजे नक्की काय? वेबसॉकेट म्हणजे ब्राउझर (किंवा कोणताही क्लायंट) आणि सर्व्हर यांच्यातील, एकाच TCP कनेक्शनवरून उघडलेला, टिकून राहणारा, फुल-डुप्लेक्स संवाद-मार्ग आहे [1]. फुल-डुप्लेक्स म्हणजे दोन्ही बाजू कधीही, हवं तेव्हा संदेश पाठवू शकतात — फक्त विनंतीला उत्तर म्हणून नाही. हाच भाग वेबबद्दलची आपली नेहमीची मानसिक रचना मोडतो.
Amazon वरील सामान्य HTTP Headers समजून घेणे
तुम्ही एखाद्या वेबसाइटला पाठवलेल्या प्रत्येक request सोबत तुम्हाला कधीही न दिसणारा metadata चा एक छोटा ढीग असतो. Headers. तुमचे connection encrypted आहे की नाही, एखादे page iframe मध्ये embed करता येईल की नाही, कोणत्या CDN edge ने तुम्हाला serve केले, आणि browser ने एखादे cookie वर्षभर लक्षात ठेवावे की नाही — हे सगळे तेच ठरवतात. एखादी खरीखुरी, गजबजलेली production site काय पाठवते हे मला बघायचे होते, म्हणून मी curl एका Amazon endpoint कडे रोखले आणि response headers बाहेर काढले. लक्षात आले की उलगडण्यासारखे बरेच काही आहे.
प्रत्येक नियम न पाळताही तुम्ही API ला RESTful म्हणू शकता का?
प्रत्येकजण आपल्या API वर “RESTful” असा शिक्का मारतो. कोणतीही docs पेज उघडा, मार्केटिंग मजकूर स्क्रोल करा, आणि तिथे ते असतेच — “आमचे स्वच्छ, RESTful API.” पण इथे अडचणीची गोष्ट अशी आहे: काटेकोर व्याख्येनुसार, त्यांपैकी जवळपास एकही प्रत्यक्षात तसे नसते. म्हणून तुम्ही जो खरा प्रश्न विचारत आहात तो असा की काही नियम मोडले तर हा शब्द अजूनही काही अर्थ राखतो का. खरे सांगायचे तर, इथेच गोष्ट किचकट बनते. आधी थोडक्यात उत्तर, कारण उत्तर शेवटी दडवून ठेवणारे लेख मला आवडत नाहीत: हो, रोजच्या संभाषणात तुम्ही त्याला अजूनही RESTful म्हणू शकता, पण नाही, रॉय फिल्डिंगच्या मूळ व्याख्येनुसार ते REST API नाही — जोपर्यंत ते hypertext-driven नसेल. या दोन्ही गोष्टी एकाच वेळी खऱ्या आहेत, आणि त्यांच्यातील अंतर हीच संपूर्ण कथा आहे.