26 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਟਿਮ ਬਰਨਰਜ਼-ਲੀ ਦਾ ਵੈੱਬ: URLs, HTTP, HTML ਅਤੇ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਜਾਣੋ ਕਿ Tim Berners-Lee ਨੇ ਕਿਵੇਂ URLs, HTTP ਅਤੇ HTML ਨੂੰ ਜੋੜ ਕੇ World Wide Web ਬਣਾਇਆ—ਅਤੇ ਇਹ ਸਧਾਰਣ ਵਿਚਾਰ ਅੱਜ ਦੇ ਆਧੁਨਿਕ ਐਪਸ ਅਤੇ APIs ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ।
ਜਾਣੋ ਕਿ Tim Berners-Lee ਨੇ ਕਿਵੇਂ URLs, HTTP ਅਤੇ HTML ਨੂੰ ਜੋੜ ਕੇ World Wide Web ਬਣਾਇਆ—ਅਤੇ ਇਹ ਸਧਾਰਣ ਵਿਚਾਰ ਅੱਜ ਦੇ ਆਧੁਨਿਕ ਐਪਸ ਅਤੇ APIs ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ।
World Wide Web (ਅਕਸਰ ਸਿਰਫ਼ “ਵੈੱਬ”) ਜਾਣਕਾਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਅਤੇ ਲਿੰਕਾਂ ਰਾਹੀਂ ਪਹੁੰਚ ਕਰਨ ਦਾ ਇਕ ਤਰੀਕਾ ਹੈ। ਇਹ ਉਹ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਪੇਜ਼ ਤੋਂ ਦੂਜੇ ਪੇਜ਼ 'ਤੇ ਕਲਿਕ ਕਰਨ, ਖੋਜ ਨਤੀਜੇ ਤੋਂ ਇੱਕ ਉਤਪਾਦ ਪੇਜ਼ ਖੋਲ੍ਹਣ ਜਾਂ ਇੱਕ ਐਸਾ ਲਿੰਕ ਸਾਂਝਾ ਕਰਨ ਦਿੰਦੀ ਹੈ ਜੋ ਲਗਭਗ ਕਿਸੇ ਵੀ ਕੰਪਿਊਟਰ ਜਾਂ ਫ਼ੋਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।
ਮੂਲ ਤੌਰ 'ਤੇ, ਵੈੱਬ ਇੱਕ ਵਿਹਾਰਕ ਤ੍ਰਿ-ਯੋਗ ਹੈ:
ਤੁਹਾਨੂੰ ਪ੍ਰੋਗਰਾਮਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਤਾਂ ਇਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ ਮਹਿਸੂਸ ਕਰੋ: ਹਰ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਲਿੰਕ ਪੇਸਟ ਕਰੋ, ਪੇਜ਼ ਲੋਡ ਕਰੋ, ਜਾਂ ਕਿਸੇ ਬਟਨ 'ਤੇ ਕਲਿਕ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਕਿਸੇ ਹੋਰ ਥਾਂ ਲੈ ਜਾਂਦਾ ਹੈ, ਤੁਸੀਂ URL + HTTP + HTML 'ਤੇ ਨਿਰਭਰ ਹੋ।
ਲੋਕ ਅਕਸਰ “ਵੈੱਬ” ਅਤੇ “ਇੰਟਰਨੈੱਟ” ਨੂੰ ਇਕੋ ਸਮਝਦੇ ਹਨ, ਪਰ ਇਹ ਵੱਖਰੇ ਹਨ:
ਈਮੇਲ, ਆਨਲਾਈਨ ਗੇਮਿੰਗ ਅਤੇ ਕਈ ਚੈਟ ਐਪਸ ਇੰਟਰਨੈੱਟ ਵਰਤਦੇ ਹਨ ਬਿਨਾਂ ਸਖਤ ਅਰਥ 'ਚ “ਵੈੱਬ” ਹੋਣ ਦੇ।
ਆਧੁਨਿਕ ਅਨੁਭਵ—single-page apps, mobile apps, ਅਤੇ APIs—ਅਜੇ ਵੀ ਇਨ੍ਹਾਂ ਬੁਨਿਆਦਾਂ 'ਤੇ ਭਾਰੀ ਨਿਰਭਰ ਹਨ। ਉਹ կարող են ਵਿਸਥਾਰਕ ਤੱਥ ਛੁਪਾ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਜ਼ਰੂਰ URLs ਨਾਲ ਰਿਸੋਰਸਾਂ ਦੀ ਪਛਾਣ, HTTP ਨਾਲ ਹਦਾਇਤਾਂ ਅਤੇ ਜਵਾਬਾਂ ਦੀ ਤਬਾਦਲਾ, ਅਤੇ ਅਕਸਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਸ ਨੂੰ bootstrap ਕਰਨ ਲਈ HTML ਵਰਤਦੇ ਹਨ।
Tim Berners-Lee “ਇੰਟਰਨੈੱਟ” ਖੋਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ। 1989 ਵਿੱਚ, CERN 'ਤੇ ਕੰਮ ਕਰਦਿਆਂ, ਉਹ ਇੱਕ ਵਿਹਾਰਕ ਤਕਲੀਫ਼ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਸੀ: ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਮੌਜੂਦ ਸੀ, ਪਰ ਇਹ ਵੱਖ-ਵੱਖ ਅਣ-ਅਨੁਕੂਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਫੈਲੀ ਹੋਈ ਸੀ, ਵੱਖ-ਵੱਖ ਫਾਰਮੇਟਾਂ ਵਿੱਚ ਸਟੋਰ ਸੀ, ਅਤੇ ਦੁਬਾਰਾ ਲੱਭਣਾ ਔਖਾ ਸੀ।
ਖੋਜਕਾਰ, ਟੀਮਾਂ ਅਤੇ ਵਿਭਾਗ ਵੱਖਰੇ ਕੰਪਿਊਟਰਾਂ ਅਤੇ ਸਾਫਟਵੇਅਰ ਵਰਤਦੇ ਸਨ। ਜਦੋਂ ਦੋ ਸਮੂਹਾਂ ਕੋਲ “ਉਹੀ” ਕਿਸਮ ਦਾ ਦਸਤਾਵੇਜ਼ ਹੁੰਦਾ, ਤਾਂ ਵੀ ਉਹ ਵੱਖ-ਵੱਖ ਥਾਂਆਂ 'ਤੇ ਰੱਖ ਸਕਦੇ ਸਨ, ਵੱਖਰਾ ਨਾਮ ਰੱਖ ਸਕਦੇ ਸਨ ਜਾਂ ਖੋਲ੍ਹਣ ਲਈ ਖਾਸ ਪ੍ਰੋਗਰਾਮ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਸੀ। ਸਾਂਝਾ ਕਰਨ ਦਾ ਮਤਲਬ ਅਕਸਰ ਫਾਈਲਾਂ ਭੇਜਣਾ, ਨਕਲਾਂ ਬਣਾਉਣਾ ਅਤੇ ਪੰਜਾਬਾ-ਨਿਯੰਤਰਣ ਖੋ ਦੇਣਾ ਹੁੰਦਾ ਸੀ।
Berners-Lee ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਸੀ ਕਿ ਕਿਸੇ ਨੂੰ ਆਪਣੀ ਕੰਪਿਊਟਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਪਬਲਿਸ਼ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਹੋਵੇ, ਅਤੇ ਦੂਜੇ ਲੋਕ ਉਸਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚ ਸਕਣ—ਬਿਨਾਂ ਮਸ਼ੀਨ ਦੀ ਕਿਸਮ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜਾਂ ਅੰਦਰੂਨੀ ਡਾਇਰੈਕਟਰੀ ਸਟ੍ਰਕਚਰ ਜਾਣਨ ਦੀ ਲੋੜ ਦੇ।
ਇਸ ਲਈ ਕੁਝ ਚੀਜ਼ਾਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨਾ ਪਿਆ:
ਉਲੰਘਣਾ ਕੋਈ ਇਕ ਫੀਚਰ ਨਹੀਂ ਸੀ—ਇਹ ਫੈਸਲਾ ਸੀ ਕਿ ਪ੍ਰਣਾਲੀ ਛੋਟਾ ਅਤੇ ਯੂਨੀਵਰਸਲ ਰੱਖੋ। ਜੇ ਨਿਯਮ ਕਾਫ਼ੀ ਸਧਾਰਣ ਹੋਣ, ਤਾਂ ਵੱਖ-ਵੱਖ ਕੰਪਿਊਟਰ ਅਤੇ ਸੰਸਥਾਵਾਂ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੀਆਂ ਅਤੇ ਫਿਰ ਵੀ ਗੱਲਬਾਤ ਕਰ ਸਕਦੀਆਂ।
ਇਸੇ ਕਾਰਨ ਤੋਂ ਖੁੱਲੇ ਮਿਆਰ ਸ਼ੁਰੂ ਤੋਂ ਅਹਮ ਸਨ: ਵੈੱਬ ਨੂੰ ਸਾਰਵਜਨਿਕ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਸੀ ਤਾਂ ਕਿ ਕਈ ਸੁਤੰਤਰ ਸਿਸਟਮ ਭਾਗ ਲੈ ਸਕਣ। ਇਹ ਸੰਯੁਕਤ ਮਿਆਰ—ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵੇਂਡਰ ਦੇ ਟੂਲਚੇਨ ਦੀ ਬਜਾਏ—ਵੈੱਬ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਣ ਯੋਗ ਅਤੇ ਨਵੇਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਅਤੇ ਸਰਵਰਾਂ ਨੂੰ ਮੌਜੂਦਾ ਸਮੱਗਰੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਦੇ ਇਕ ਗੰਦੇ ਦਫ਼ਤਰ ਡਰਾਈਵ 'ਤੇ “ਫਾਈਲ ਸਾਂਝਾ ਕਰਨ” ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮੁੱਖ ਸਮੱਸਿਆ ਦੇਖੀ ਹੋਵੇਗੀ: ਚੀਜ਼ਾਂ ਨੂੰ ਲਗਾਤਾਰ ਨਾਂ ਦੇਣਾ ਔਖਾ ਹੈ। ਵੱਖ-ਵੱਖ ਕੰਪਿਊਟਰ ਵੱਖ-ਵੱਖ ਥਾਂਆਂ 'ਤੇ ਜਾਣਕਾਰੀ ਰੱਖਦੇ ਹਨ, ਫੋਲਡਰ ਪੁਨਰ-ਸੰਰਚਿਤ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਕੋ ਨਾਮ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਸਾਂਝੇ ਨਾਂ ਪ੍ਰਣਾਲੀ ਬਿਨਾਂ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਕਹਿ ਸਕਦੇ “ਉੱਥੇ ਵਾਲੀ ਉਹ ਚੀਜ਼ ਲੈ ਆਓ।”
URLs ਨੇ World Wide Web ਲਈ ਇਹ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ ਅਤੇ ਇੱਕ ਯੂਨੀਵਰਸਲ, copy-and-paste ਯੋਗ ਪਤਾ ਦਿੱਤਾ।
ਇੱਥੇ ਇੱਕ ਉਦਾਹਰਣ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਜਾਣੂ ਲੱਗ ਸਕਦੀ ਹੈ:
https://www.example.com:443/products/shoes?color=black\u0026size=42#reviews
ਹਰ ਹਿੱਸੇ ਦਾ ਸਧਾਰਨ ਅਰਥ:
ਇੱਕ URL ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕੁਝ ਨਿਸ਼ਾਨਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਰਵਰ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ: HTML ਪੇਜ਼, ਤਸਵੀਰ, PDF, ਡਾਊਨਲੋਡ ਕਰਨ ਯੋਗ ਫਾਈਲ, ਜਾਂ ਇੱਕ ਐਪ ਲਈ API ਐਂਡਪਾਇੰਟ।
ਉਦਾਹਰਣ:
/images/logo.png (ਇੱਕ ਤਸਵੀਰ)/docs/terms.pdf (ਇੱਕ ਦਸਤਾਵੇਜ਼)/api/orders/123 (ਇੱਕ ਐਪ ਲਈ ਡਾਟਾ)ਲੋਕ ਅਕਸਰ ਇਹ ਸ਼ਬਦ ਇਕ ਦੋਸਰੇ ਦੇ ਬਦਲੇ ਵਰਤਦੇ ਹਨ:
ਅਮਲ ਵਿੱਚ, “URL = ਪਤਾ” ਸੋਚ ਕੇ ਤੁਸੀਂ 95% ਹੋਂਦ ਤਕ ਪੁੱਜ ਜاؤਗੇ।
HTTP ਵੈੱਬ ਦੀ ਮੂਲ ਗੱਲਬਾਤ ਸ਼ੈਲੀ ਹੈ। ਇਹ ਇਕ ਸਧਾਰਨ ਸੌਦਾ ਹੈ: ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਕੋਈ ਚੀਜ਼ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਜੋ ਕੁਝ ਉਸ ਕੋਲ ਹੈ ਉਹ ਵਾਪਸ ਭੇਜਦਾ ਹੈ (ਜਾਂ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਉਂ ਨਹੀਂ)।
ਜਦੋਂ ਤੁਸੀਂ URL ਲਿਖਦੇ ਹੋ ਜਾਂ ਕੋਈ ਲਿੰਕ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਸਰਵਰ ਨੂੰ HTTP request ਭੇਜਦਾ ਹੈ। ਰਿਕਵੇਸਟ ਇੱਕ ਨੋਟ ਵਾਂਗ ਹੈ ਜੋ ਕਹਿੰਦੀ ਹੈ: “ਮੈਨੂੰ ਇਹ ਖਾਸ ਰਿਸੋਰਸ ਚਾਹੀਦਾ ਹੈ।”
ਸਰਵਰ ਫਿਰ HTTP response ਭੇਜਦਾ ਹੈ—ਇਹ ਪੈਕੇਜ ਹੈ ਜਿਸ ਵਿੱਚ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਜੋ ਮੰਗਿਆ ਸੀ ਉਹ ਸਮੱਗਰੀ (ਜਿਵੇਂ ਪੇਜ਼), ਜਾਂ ਕੋਈ ਸੁਚਨਾ ਕਿ ਕੁਛ ਹੋਰ ਹੋਇਆ।
HTTP ਰਿਕਵੇਸਟਾਂ ਵਿੱਚ ਇੱਕ method ਹੁੰਦੀ ਹੈ, ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਕੀ ਕਰ ਰਹੇ ਹੋ ਉਸ ਦੀ ਕਿਸਮ ਦੱਸਦੀ ਹੈ।
GET ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ 'ਤੇ ਕੁਛ ਨਹੀਂ ਬਦਲਦਾ; ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਪੜ੍ਹਨ ਲਈ ਹੁੰਦਾ ਹੈ। POST ਅਕਸਰ ਉਸ ਵੇਲੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਭੇਜ ਰਹੇ ਹੋ ਜੋ ਪ੍ਰੋਸੈਸ ਕੀਤੀ ਜਾਵੇ।
ਹਰ ਜਵਾਬ ਵਿੱਚ ਇੱਕ ਸਟੇਟਸ ਕੋਡ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ—ਇਸਨੂੰ ਡਿਲਿਵਰੀ ਨਤੀਜੇ ਵਜੋਂ ਸੋਚੋ।
ਰਿਕਵੇਸਟ ਅਤੇ ਰਿਸਪਾਂਸਾਂ ਵਿੱਚ headers ਵੀ ਹੁੰਦੇ ਹਨ, ਜੋ ਲੇਬਲ ਵਾਂਗ ਹੁੰਦੇ ਹਨ: “ਇਹ ਮੈਂ ਕੌਣ ਹਾਂ,” “ਮੈਂ ਕੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹਾਂ,” ਜਾਂ “ਇਸ ਸਮੱਗਰੀ ਨੂੰ ਕਿਵੇਂ ਹینڈਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।”
ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਲੇਬਲਾਂ ਵਿੱਚੋਂ ਇੱਕ Content-Type ਹੈ, ਜਿਵੇਂ text/html ਇੱਕ ਵੈੱਬ ਪੇਜ਼ ਲਈ ਜਾਂ application/json ਡੇਟਾ ਲਈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਦਰ ਕੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾ ਸਕੇ।
HTML (HyperText Markup Language) ਪੇਜ਼ ਦੇ ਢਾਂਚੇ ਨੂੰ ਵਰਨਨ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ—ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਸਮੱਗਰੀ ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਸੰਗਠਿਤ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਸਮਝੋ ਜਿਸ 'ਤੇ ਲੇਬਲ ਲੱਗੇ ਹੁੰਦੇ ਹਨ: “ਇਹ ਸਿਰਲੇਖ ਹੈ,” “ਇਹ ਇਕ ਪੈਰਾ ਹੈ,” “ਇਹ ਇੱਕ ਲਿੰਕ ਹੈ,” “ਇਹ ਫਾਰਮ ਫੀਲਡ ਹੈ।”
HTML ਟੈਗਾਂ ਨਾਲ ਸਮੱਗਰੀ ਨੂੰ ਮਾਰਕਅਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਕ ਟੈਗ ਆਮ ਤੌਰ 'ਤੇ ਖੁਲ੍ਹਣ ਅਤੇ ਬੰਦ ਹੋਣ ਵਾਲੀ ਵਰਜਨ ਹੁੰਦੀ ਹੈ, ਜੋ ਉਸ ਸਮੱਗਰੀ ਨੂੰ ਘੇਰਦੀ ਹੈ ਜੋ ਉਹ ਵਰਨਨ ਕਰਦੀ ਹੈ।
ਸਿਰਲੇਖ ਅਤੇ ਪੈਰਾਗ੍ਰਾਫ ਪੇਜ਼ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਸਿਰਲੇਖ ਲੋਕਾਂ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੱਸਦਾ ਹੈ, “ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੈਕਸ਼ਨ ਟਾਈਟਲ ਹੈ।” ਇੱਕ ਪੈਰਾ ਦੱਸਦਾ ਹੈ, “ਇਹ ਬਾਡੀ ਟੈਕਸਟ ਹੈ।”
ਲਿੰਕ ਅਤੇ ਤਸਵੀਰਾਂ ਵੀ HTML ਵਿੱਚ ਦਰਸਾਏ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਤਸਵੀਰ ਟੈਗ ਇੱਕ ਤਸਵੀਰ ਫਾਈਲ ਦੀ ਨੁਕਤਾ ਕਰਦਾ ਹੈ (ਇੱਕ ਰਿਸੋਰਸ), ਜਦਕਿ ਇੱਕ ਲਿੰਕ ਟੈਗ ਦੂਜੇ URL ਨੂੰ ਨਿਸ਼ਾਨਾ ਕਰਦਾ ਹੈ।
HTML ਦੇ “HT”—hypertext—ਨੇ ਵੱਡਾ ਵਿਚਾਰ ਪੇਸ਼ ਕੀਤਾ ਜੋ ਵੈੱਬ ਨੂੰ ਪਹਿਲਾਂ ਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਵੱਖਰਾ ਮਹਿਸੂਸ ਕਰਵਾਇਆ। ਮੇਨੂ, ਫੋਲਡਰ ਜਾਂ ਖਾਸ ਕਮਾਂਡਾਂ ਨਾਲ ਨੈਵੀਗੇਸ਼ਨ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਟੈਕਸਟ ਵਿਚ ਕੀਤੇ ਕਲਿਕ ਯੋਗ ਲਿੰਕਾਂ ਰਾਹੀਂ ਸਿੱਧਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਦੂਜੇ 'ਤੇ ਛੱਲ ਮਾਰ ਸਕਦੇ ਹੋ।
ਇਹ ਬਦਲਾਅ ਸਾਦਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਸ਼ਕਤਿਸ਼ਾਲੀ ਹੈ: ਗਿਆਨ ਜੁੜ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਪੇਜ਼ ਸਰੋਤ, ਸੰਬੰਧਤ ਵਿਸ਼ੇ, ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਅਗਲੇ ਕਦਮਾਂ ਨੂੰ ਤੁਰੰਤ ਦਰਸਾ ਸਕਦਾ ਹੈ—ਹਰ ਵਾਰ ਕੇਂਦਰੀ ਇੰਡੈਕਸ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।
ਇੱਥੇ ਇੱਕ ਬੁਨਿਆਦੀ ਲਿੰਕ ਕਿੱਦਾ ਵੇਖਦਾ ਹੈ:
\u003ca href=\"/blog/how-http-works\"\u003eRead more about HTTP\u003c/a\u003e
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: “ਦਿਖਾਓ ਸ਼ਬਦ Read more about HTTP ਅਤੇ ਜਦੋਂ ਇਸ 'ਤੇ ਕਲਿਕ ਕੀਤਾ ਜਾਵੇ, ਪਾਠਕ ਨੂੰ /blog/how-http-works ਵਾਲੇ ਪੇਜ਼ ਉੱਤੇ ਲੈ ਜਾਓ।”
HTML ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਪਬਲਿਸ਼ ਕਰਨ ਲਈ ਨਹੀਂ ਹੈ। ਇਹ ਇਨਪੁੱਟ ਜਿਵੇਂ ਟੈਕਸਟ ਫੀਲਡ, ਚੈੱਕਬਾਕਸ ਅਤੇ ਬਟਨ ਵੀ ਦਰਸਾ ਸਕਦਾ ਹੈ। ਇਹ ਟੁਕੜੇ ਇੱਕ ਪੇਜ਼ ਨੂੰ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ (ਜਿਵੇਂ ਲੋਗਇਨ, ਖੋਜ, ਜਾਂ ਚੈਕਆਉਟ) ਅਤੇ ਇਸਨੂੰ ਸਰਵਰ ਨੂੰ ਭੇਜਦੇ ਹਨ।
ਇਹਨਾਂ ਨੂੰ ਮਿਸ਼ਰਤ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਪਰ ਉਹਨਾਂ ਦੇ ਕੰਮ ਵੱਖਰੇ ਹਨ:
ਜੇਕਰچہ ਵੈੱਬ ਐਪਸ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਚੁੱਕੀਆਂ ਹਨ, HTML ਅਜੇ ਵੀ ਸ਼ੁਰੂਆਤ ਦਾ ਬਿੰਦੂ ਹੈ: ਇਹ ਇੱਕ ਸਾਂਝੀ, ਪੜ੍ਹਨ ਯੋਗ ਤਰੀਕਾ ਹੈ ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਪੇਜ਼ ਵਿੱਚ ਕੀ ਹੈ—ਅਤੇ ਇਹ ਕਿ ਅਗਲਾ ਰਸਤਾ ਕਿੱਥੇ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਵੈੱਬਸਾਈਟ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਮੂਲ ਤੌਰ 'ਤੇ ਦੋ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: ਸਹੀ ਕੰਪਿਊਟਰ ਲੱਭਣਾ ਅਤੇ ਸਹੀ ਫਾਈਲ ਮੰਗਣਾ।
ਇੱਕ URL (ਜਿਵੇਂ https://example.com/page) ਪੇਜ਼ ਦਾ ਐਡਰੈੱਸ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ host name (example.com) ਅਤੇ ਅਕਸਰ ਇੱਕ path (/page) ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ।
ਇੰਟਰਨੈੱਟ 'ਤੇ ਕੰਪਿਊਟਰ ਨੰਬਰਿਕ ਪਤੇ (IP addresses) ਵਰਤਦੇ ਹਨ। DNS (Domain Name System) ਇਕ ਫੋਨ ਬੁੱਕ ਵਾਂਗ ਹੈ ਜੋ example.com ਨੂੰ ਇੱਕ IP ਪਤੇ ਨਾਲ ਮੇਲ ਕਰਦਾ ਹੈ।
ਇਹ ਲੁਕਅਪ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ—ਅਤੇ ਕਦੇ-ਕਦੇ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹਾਲੀਆ ਦੌਰੇ ਤੋਂ ਸਟੋਰ ਕੀਤਾ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।
ਹੁਣ ਬ੍ਰਾਊਜ਼ਰ ਉਸ IP ਪਤੇ 'ਤੇ ਸਰਵਰ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ। ਜੇ URL https:// ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਇਨਕ੍ਰਿਪਟ ਕੀਤੀ ਹੋਈ ਕਨੈਕਸ਼ਨ ਵੀ ਸੈੱਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਹੋਰ ਲੋਕ ਸੌਖੇ ਤਰੀਕੇ ਨਾਲ ਭੇਜੇ ਹੋਏ ਨੂੰ ਨਾ ਪੜ੍ਹ ਸਕਣ।
HTTP (Hypertext Transfer Protocol) ਵੈੱਬ ਦੀ “ਰਿਕਵੇਸਟ-ਅਤੇ-ਰਿਸਪਾਂਸ” ਭਾਸ਼ਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ HTTP ਰਿਕਵੇਸਟ ਭੇਜਦਾ ਹੈ: “ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ /page ਦਿਓ।”
ਸਰਵਰ ਇੱਕ HTTP ਰਿਸਪਾਂਸ ਦੇ ਕੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਟੇਟਸ (ਜਿਵੇਂ “OK” ਜਾਂ “Not Found”) ਅਤੇ ਸਮੱਗਰੀ ਸ਼ਾਮਿਲ ਹੁੰਦੀ ਹੈ।
ਉਹ ਸਮੱਗਰੀ ਅਕਸਰ HTML ਹੁੰਦੀ ਹੈ। HTML ਇਕ ਸਧਾਰਣ ਫਾਰਮੈਟ ਹੈ ਜੋ ਪੇਜ਼ ਦੀ ਸੰਰਚਨਾ ਨੂੰ ਵਰਨਨ ਕਰਦਾ—ਸਿਰਲੇਖ, ਪੈਰਾ, ਲਿੰਕ ਆਦਿ।
ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ HTML ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਹ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਹੋਰ ਫਾਈਲਾਂ ਦੀ ਲੋੜ ਵੀ ਹੈ (CSS ਸ਼ੈਲਿੰਗ ਲਈ, JavaScript ਇੰਟਰਏਕਸ਼ਨ ਲਈ, ਤਸਵੀਰਾਂ, ਫੋਂਟ)। ਫਿਰ ਉਹ ਹਰ ਇਕ ਲਈ ਇੱਕੋ ਹੀ HTTP ਰਿਕਵੇਸਟ/ਰਿਸਪਾਂਸ ਧਾਰਾ ਦੋਹਰਾਉਂਦਾ ਹੈ।
ਫਾਸਟ ਲੋਡਿੰਗ ਲਈ, ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ cache ਰੱਖਦਾ ਹੈ—ਉਹ ਫਾਈਲਾਂ ਦੀ ਇਕ ਸੇਵ ਕਾਪੀ ਜਿਹੜੀਆਂ ਉਹ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕਰ ਚੁੱਕਿਆ ਹੈ। ਜੇ ਕੁਛ ਬਦਲਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਕਾਪੀ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ ਬਜਾਏ ਫਿਰ ਤੋਂ ਡਾਊਨਲੋਡ ਕਰਨ ਦੇ।
ਤੇਜ਼ ਚੈੱਕਲਿਸਟ (ਫਲੋ):
ਜਦੋਂ ਲੋਕ “ਵੈੱਬ” ਕਹਿੰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਇੱਕ ਨਰਮ ਅਨੁਭਵ ਦਾ ਮਤਲਬ ਲੈਂਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਲਿੰਕ 'ਤੇ ਟੈਪ ਕਰਦੇ ਹੋ ਅਤੇ ਪੇਜ਼ ਆ ਜਾਂਦਾ ਹੈ। ਹੇਠਾਂ, ਇਹ ਇਕ ਸਧਾਰਣ ਸੰਬੰਧ ਹੈ: ਸਰਵਰ, ਬ੍ਰਾਊਜ਼ਰ, ਅਤੇ ਰਿਸੋਰਸ।
ਇੱਕ server ਇੱਕ ਕੰਪਿਊਟਰ (ਜਾਂ ਕੰਪਿਊਟਰਾਂ ਦਾ ਕਲੱਸਟਰ) ਹੁੰਦਾ ਹੈ ਜੋ ਇੰਟਰਨੈੱਟ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ ਅਤੇ URLs 'ਤੇ ਰਿਸੋਰਸਾਂ ਨੂੰ ਹੋਸਟ ਕਰਦਾ ਹੈ। ਜੇ URL ਇੱਕ ਐਡਰੈੱਸ ਹੈ, ਤਾਂ ਸਰਵਰ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਉਸ ਐਡਰੈੱਸ 'ਤੇ ਆਉਣ ਵਾਲਿਆਂ ਦੀ ਸੇਵਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਹ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਭੇਜਣਾ ਹੈ।
ਉਹ “ਚੀਜ਼” ਜੋ ਸਰਵਰ ਭੇਜਦਾ ਹੈ, ਇੱਕ ਵੈੱਬ ਪੇਜ਼, ਇੱਕ ਫਾਈਲ ਜਾਂ ਡਾਟਾ ਹੋ ਸਕਦੀ ਹੈ। ਮੁੱਖ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਸਰਵਰ ਕਿਸੇ ਖਾਸ URL ਲਈ ਆਉਣ ਵਾਲੀਆਂ ਰਿਕਵੇਸਟਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਸੈਟ ਕੀਤਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ browser ਇੱਕ ਪ੍ਰੋਗਰਾਮ (ਜਿਵੇਂ Chrome, Safari, ਜਾਂ Firefox) ਹੈ ਜੋ ਸਰਵਰਾਂ ਤੋਂ ਰਿਸੋਰਸਾਂ ਨੂੰ ਫੈਚ ਕਰਦਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਨੁੱਖ-ਪਾਠਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ URL ਦਰਜ ਕਰਦੇ ਹੋ ਜਾਂ ਲਿੰਕ 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਬ੍ਰਾਊਜ਼ਰ:
ਇੱਕ resource ਉਹ ਕੁਝ ਵੀ ਹੈ ਜੋ ਵੈੱਬ ਇੱਕ URL 'ਤੇ ਪਛਾਣ ਕਰਕੇ ਡਿਲਿਵਰ ਕਰ ਸਕਦਾ ਹੈ। ਆਮ ਉਦਾਹਰਣ ਹਨ:
ਇਹੀ ਮਾਡਲ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ। ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਵੀ ਇੱਕ URL-ਉੱਤੇ ਮੰਗ ਕਰ ਸਕਦੀ ਹੈ—ਅਕਸਰ ਇੱਕ ਵੈੱਬ API ਐਂਡਪਾਇੰਟ—ਅਤੇ ਐਪ ਆਪਣੀ ਇੰਟਰਫੇਸ ਵਿੱਚ ਡਾਟਾ ਦਰਸਾਉਂਦੀ ਹੈ। ਭੂਮਿਕਾ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦੀ ਹੈ: ਐਪ ਕਲਾਇੰਟ, ਸਰਵਰ ਹੋਸਟ, ਅਤੇ API ਰਿਸੋਰਸ।
ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਪੇਜ਼ ਜ਼ਿਆਦਾਤਰ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦੇ ਸਨ। ਫਾਰਮ ਉਸ ਸਮੇ ਨੂੰ ਆਣਦੇ ਹਨ ਜਦੋਂ ਵੈੱਬ ਜਾਣਕਾਰੀ ਇਕੱਤਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ—ਇੱਕ ਪੇਜ਼ ਇੱਕ ਦੋ-ਤਰਫ਼ੀ ਗੱਲਬਾਤ ਬਣ ਜਾਂਦਾ ਹੈ।
HTML ਫਾਰਮ ਫੀਲਡਾਂ (ਟੈਕਸਟ ਬਾਕਸ, ਚੈੱਕਬਾਕਸ, ਬਟਨ) ਦਾ ਇੱਕ ਢਾਂਚਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦੋ ਅਹਮ ਹਦਾਇਤਾਂ:
action URL)method, ਆਮ ਤੌਰ 'ਤੇ GET ਜਾਂ POST)ਜਦੋਂ ਤੁਸੀਂ “Submit” 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਬ੍ਰਾਊਜ਼ਰ ਜੋ ਤੁਸੀਂ ਟਾਈਪ ਕੀਤਾ ਉਹ ਪੈਕੇਜ ਕਰਕੇ ਉਸ URL 'ਤੇ HTTP ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ। ਇਹ “ਇੱਕ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਫੀਲਡ” ਤੋਂ “ਇੱਕ ਐਪ ਜੋ ਇਨਪੁੱਟ ਪ੍ਰੋਸੈਸ ਕਰਦੀ” ਵੱਲ ਪੁਲ ਬਣਾਉਂਦਾ ਹੈ।
ਉੱਚ ਸਤਰ 'ਤੇ:
ਇਸ ਲਈ ਇੱਕ ਖੋਜ /search?q=shoes (GET) ਹੋ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਚੈਕਆਉਟ ਆਮ ਤੌਰ 'ਤੇ /checkout 'ਤੇ POST ਕਰ ਸਕਦਾ ਹੈ।
ਸਰਵਰ ਪਾਸੇ, ਇੱਕ ਪ੍ਰੋਗਰਾਮ HTTP ਰਿਕਵੇਸਟ ਪ੍ਰਾਪਤ ਕਰਦਾ, ਭੇਜੇ ਹੋਏ ਮੁੱਲਾਂ ਨੂੰ ਪੜ੍ਹਦਾ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ:
ਸਰਵਰ ਫਿਰ ਜਵਾਬ ਦਿੰਦਾ—ਅਕਸਰ ਇੱਕ ਨਵਾਂ HTML ਪੇਜ਼ (“ਧੰਨਵਾਦ!”), ਇੱਕ ਤਰੁੱਟੀ ਸੁਨੇਹਾ, ਜਾਂ ਹੋਰ URL 'ਤੇ redirect।
ਜੇ ਫਾਰਮ ਵਿੱਚ ਕੁਝ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ—ਪਾਸਵਰਡ, ਪਤੇ, ਭੁਗਤਾਨ ਵੇਰਵੇ—HTTPS ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਤੇ ਹੋਰ ਲੋਕ ਜੋ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਹੈ ਉਹ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦੇ ਜਾਂ ਬਦਲ ਨਹੀਂ ਸਕਦੇ। ਬਿਨਾਂ HTTPS ਦੇ, ਸਧਾਰਣ ਲੌਗਇਨ ਫਾਰਮ ਵੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਘਾੜ ਸਕਦਾ ਹੈ।
ਆਧੁਨਿਕ “ਐਪਸ” ਸਿਰਫ਼ ਵੈੱਬ ਪੇਜ਼ ਨਹੀਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਵੈੱਬ + ਕੋਡ ਹਨ: ਇੱਕ HTML ਪੇਜ਼ ਜੋ JavaScript ਅਤੇ CSS ਲੋਡ ਕਰਦਾ ਹੈ, ਫਿਰ ਉਹ ਕੋਡ ਬਿਨਾਂ ਪੂਰੇ ਪੇਜ਼ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ ਦਿਖਾਵਟ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਚਾਹੇ ਇੱਕ ਐਪ ਨੇਟਿਵ ਪ੍ਰੋਗਰਾਮ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੋਵੇ (ਅਨੰਤ ਸਕ੍ਰੋਲ ਫੀਡ, ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟ), ਇਹ ਅਜੇ ਵੀ ਉਹੀ ਤਿੰਨ ਬਿਲਡਿੰਗ ਬਲਾਕ ਵਰਤਦਾ ਹੈ ਜੋ Tim Berners-Lee ਨੇ ਪੇਸ਼ ਕੀਤੇ।
URL ਸਿਰਫ਼ “ਇੱਕ ਪੇਜ਼” ਲਈ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਕਿਸੇ ਵੀ ਰਿਸੋਰਸ ਲਈ ਐਡਰੈੱਸ ਹੈ: ਇੱਕ ਉਤਪਾਦ, ਇੱਕ ਯੂਜ਼ਰ ਪ੍ਰੋਫ਼ਾਈਲ, ਇੱਕ ਖੋਜ, ਇੱਕ ਫੋਟੋ, ਜਾਂ “ਸੈਂਡ ਮੈਸੇਜ” ਐਂਡਪਾਇੰਟ। ਵਧੀਆ ਐਪਸ URLs ਨੂੰ ਵਰਤਦੇ ਹਨ ਤਾਂ ਜੋ ਸਮੱਗਰੀ ਸਾਂਝਾ ਕਰਨਯੋਗ, ਬੁੱਕਮਾਰਕ ਕਰਨਯੋਗ ਅਤੇ ਲਿੰਕ ਕਰਨਯੋਗ ਰਹੇ—ਇਹ ਵੈੱਬ ਦਾ ਮੁੱਖ ਵਰਤਾਰਾ ਹੈ।
ਪਿਛੋਕੜ ਵਿੱਚ, ਐਪ HTTP ਰਿਕਵੇਸਟ ਭੇਜਦੇ ਹਨ ਅਤੇ HTTP ਰਿਸਪਾਂਸ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਬਿਲਕੁਲ ਕਲਾਸਿਕ ਵੈੱਬਸਾਈਟਾਂ ਵਾਂਗ। ਨਿਯਮ ਇੱਕੋ ਹੀ ਹਨ ਭਾਵੇਂ ਤੁਸੀਂ HTML ਪੇਜ਼ ਲੈ ਰਹੇ ਹੋ ਜਾਂ ਸਕਰੀਨ ਦੇ ਇਕ ਹਿੱਸੇ ਲਈ ਡੇਟਾ ਲੋਡ ਕਰ ਰਹੇ ਹੋ:
ਅਕਸਰ ਆਧੁਨਿਕ ਐਪਸ APIs ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ: URL ਜੋ ਡੇਟਾ (ਅਕਸਰ JSON) HTTP ਉੱਤੇ ਰਿਟਰਨ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਣ:
HTML ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਕਸਰ ਸ਼ੁਰੂਆਤ ਦਾ ਬਿੰਦੂ (ਅਤੇ ਕਈ ਵਾਰੀ fallback) ਹੁੰਦਾ ਹੈ। ਵਿਆਪਕ ਤੌਰ 'ਤੇ, ਵੈੱਬ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਹੈ: ਜੇ ਸਿਸਟਮ URLs ਅਤੇ HTTP 'ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਉਹ ਜੁੜ ਸਕਦੇ ਹਨ—ਚਾਹੇ ਕਿਸ ਨੇ ਬਣਾਇਆ ਹੋਵੇ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕ ਇਹ ਬਲਾਕਸ ਦਿੱਖਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਛੋਟੀ ਚੀਜ਼ ਬਣਾਉ: ਉਦਾਹਰਣ ਲਈ ਇੱਕ React ਫਰੰਟਐਂਡ ਜੋ JSON API ਨਾਲ ਗੱਲ ਕਰਦਾ ਅਤੇ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਲਈ ਸਾਂਝੇ-ਯੋਗ URLs ਰੱਖਦਾ। ਜਿਵੇਂ ਸੰਦ Koder.ai ਇਸੇ ਮਾਡਲ 'ਤੇ ਟਿਕਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਐਪ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਇਹ ਇੱਕ ਸਧਾਰਣ ਵੈੱਬ ਸਟੈਕ (React ਫਰੰਟਐਂਡ, Go + PostgreSQL ਬੈਕਏਂਡ) ਜਨਰੇਟ ਕਰ ਦਿੰਦਾ ਹੈ—ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਕੀਕਤੀ URLs, HTTP ਐਂਡਪਾਇੰਟ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ-ਡਿਲਿਵਰ ਕੀਤੀ HTML ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਸਿਰਫ਼ ਘੱਟ ਮੈਨੁਅਲ ਸੈਟਅਪ ਨਾਲ।
ਵੈੱਬ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਂਝੇ ਮਿਆਰਾਂ 'ਤੇ ਬਣਿਆ ਹੈ—ਉਹ ਪਬਲਿਕ “ਰਸਤੇ ਦੇ ਨਿਯਮ” ਜੋ ਵੱਖ-ਵੱਖ ਸਿਸਟਮਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਕੰਪਨੀ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਕਿਸੇ ਹੋਰ ਦੁਆਰਾ ਚਲਾਏ ਸਰਵਰ ਤੋਂ ਇੱਕ ਪੇਜ਼ ਮੰਗ ਸਕਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੋਵੇ—ਕਿਉਂਕਿ ਉਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ (URLs, HTTP, HTML) 'ਤੇ ਸਹਿਮਤ ਹਨ।
ਬਿਨਾਂ ਮਿਆਰਾਂ ਦੇ, ਹਰ ਸਾਈਟ ਦੇਖਣ ਲਈ ਹਰ ਕਿਸੇ ਨੂੰ ਇਕ ਕਸਟਮ ਐਪ ਦੀ ਲੋੜ ਪੈਂਦੀ ਅਤੇ ਹਰ ਨੈੱਟਵਰਕ ਦੀ ਆਪਣੀ ਨਿੱਜੀ ਤਰੀਕ ਹੋਵੇਗੀ। ਮਿਆਰ ਹੇਠਾਂ ਦਿੱਤੇ ਮੂਲ ਸਵਾਲ ਸਲਝਾਉਂਦੇ ਹਨ:
ਜਦੋਂ ਇਹ ਨਿਯਮ ਇੱਕੋ ਜਿਹੇ ਹਨ, ਵੈੱਬ “mix and match” ਬਣ ਜਾਂਦਾ ਹੈ: ਕੋਈ ਵੀ compliant browser + ਕੋਈ ਵੀ compliant server = ਕੰਮ ਕਰਦਾ ਹੈ।
ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮਿਆਰ ਸੁਧਰੇ ਜਾ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਨੀਵਾਂ ਵਿਚਾਰ ਪਛਾਣਯੋਗ ਰਹਿੰਦਾ ਹੈ। HTTP ਦੇ ਪਹਿਲੇ ਵਰਜਨਾਂ ਤੋਂ HTTP/1.1, ਫਿਰ HTTP/2 ਅਤੇ HTTP/3 ਤੱਕ ਭੇਤਰ ਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਵਧੀ ਹੈ। ਫਿਰ ਵੀ ਮੁੱਖ ਵਿਚਾਰ ਬਰਕਰਾਰ ਹੈ: ਇੱਕ ਕਲਾਇੰਟ ਇੱਕ URL ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਸਟੇਟਸ ਕੋਡ, ਹੈਡਰ ਅਤੇ ਬਾਡੀ ਦੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
HTML ਵੀ ਵਿਕਸਿਤ ਹੋਇਆ—ਸਧਾਰਣ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਲੈ ਕੇ ਧਨਵੰਤ semantics ਅਤੇ ਐੰਬੇਡਡ ਮੀਡੀਆ—ਪਰ ਮੁੱਖ ਸੰਕਲਪ ਪੇਜ਼ ਅਤੇ ਹਾਈਪਰਲਿੰਕ ਦਾ ਰਹਿੰਦਾ ਹੈ।
ਵੈੱਬ ਦੀ ਲੰਬੀ ਉਮਰ ਦਾ ਬਹੁਤ ਹਿੱਸਾ ਬੈਕਵਰਡਸ ਕੰਪੈਟਬਿਲਿਟੀ ਦੀ ਤਰਜੀਹ ਹੈ। ਨਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਪੁਰਾਣੇ ਪੇਜ਼ਾਂ ਨੂੰ ਅਜੇ ਵੀ render ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ; ਨਵੇਂ ਸਰਵਰ ਪੁਰਾਣੀ HTTP ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਸਮਝਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਮੱਗਰੀ ਅਤੇ ਲਿੰਕ ਸਾਲਾਂ—ਅਕਸਰ ਦਹਾਕਿਆਂ—ਤਕ ਜ਼ਿੰਦੇ ਰਹਿ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਸਾਈਟ ਜਾਂ ਐਪ ਚੰਗੀ ਤਰ੍ਹਾਂ ਉਮਰ ਪਾਵੇ, ਤਾਂ ਮਿਆਰ-ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨ 'ਤੇ ਨਿਰਭਰ ਰਹੋ: ਸਾਂਝੇ-ਯੋਗ ਰਾਜਾਂ ਲਈ ਅਸਲੀ URLs ਵਰਤੋ, ਕੈਸ਼ਿੰਗ ਅਤੇ ਸਟੇਟਸ ਕੋਡ ਲਈ HTTP ਰੀਤੀ ਅਨੁਸਰ ਕਰੋ, ਅਤੇ ਵਾਧੂ ਪਰਤਾਂ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਵੈਧ HTML ਲਿਖੋ। ਮਿਆਰ ਪਾਬੰਦੀ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਉਹ ਹਨ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਨੂੰ ਪੋਰਟੇਬਲ, ਭਰੋਸੇਯੋਗ ਅਤੇ ਭਵਿੱਖ-ਮਿਤਲਯੋਗ ਰੱਖਦੇ ਹਨ।
ਭਾਵੇਂ ਤੁਸੀਂ ਵੈੱਬ ਦੀ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਕੁਝ ਸ਼ਬਦ ਐਸੇ ਹਨ ਜੋ ਅਕਸਰ ਗਲਤ ਸਮਝੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਜੋ ਛੋਟੀ-ਝੋਟੀਆਂ ਗੱਲਾਂ ਨੂੰ ਗਲਤ ਰਸਤੇ 'ਤੇ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਥੇ ਆਮ ਗਲਤਫਹਿਮੀਆਂ ਅਤੇ ਝਟਪਟ ਅਮਲਯੋਗ ਸੁਧਾਰ ਹਨ।
ਗਲਤਫਹਮੀ: Internet ਅਤੇ World Wide Web ਇਕੋ ਹੀ ਚੀਜ਼ ਹਨ।
ਝਟਪਟ ਸੁਧਾਰ: Internet ਗਲੋਬਲ ਨੈੱਟਵਰਕ ਹੈ (ਕੇਬਲ, ਰੂਟਰ, ਕੁਨੈਕਸ਼ਨ)। Web ਉਸ ਉੱਤੇ ਚੱਲਣ ਵਾਲੀ ਇੱਕ ਸੇਵਾ ਹੈ, ਜੋ URLs, HTTP, ਅਤੇ HTML ਤੋਂ ਬਣੀ ਹੈ।
ਗਲਤਫਹਮੀ: “ਮੇਰਾ URL example.com ਹੈ।”
ਝਟਪਟ ਸੁਧਾਰ: example.com ਇੱਕ ਡੋਮੇਨ ਹੈ। ਇੱਕ URL ਵਿੱਚ ਹੋਰ ਵੀ ਵੇਰਵੇ ਹੋ ਸਕਦੇ ਹਨ—ਜਿਵੇਂ path ਅਤੇ query—ਜੋ ਸਰਵਰ ਦੇ ਵਾਪਸ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਨਤੀਜੇ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ।
ਉਦਾਹਰਣ:
https://example.com/pricinghttps://example.com/search?q=shoesਇਹ ਵਾਧੂ ਹਿੱਸੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਸਰਵਰ ਕੀ ਵਾਪਸ ਕਰੇਗਾ।
ਗਲਤਫਹਮੀ: HTML ਅਤੇ HTTP ਅਦਲਾ-ਬਦਲੀ ਬਣ ਜਾਂਦੇ ਹਨ।
ਝਟਪਟ ਸੁਧਾਰ: HTTP “ਡਿਲਿਵਰੀ ਗੱਲਬਾਤ” ਹੈ (ਰਿਕਵੇਸਟ ਅਤੇ ਰਿਸਪਾਂਸ)। HTML ਇੱਕ ਸੰਭਵ “ਪੈਕੇਜ” ਹੈ ਜੋ ਡਿਲਿਵਰ ਕੀਤਾ ਜਾ ਸਕਦਾ—ਅਕਸਰ ਉਹ ਪੇਜ਼ ਨੂੰ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਲਿੰਕ ਦਰਸਾਉਂਦਾ ਹੈ। HTTP JSON ਡਾਟਾ, ਤਸਵੀਰਾਂ, PDFs, ਜਾਂ ਵੀਡੀਓ ਵੀ ਡਿਲਿਵਰ ਕਰ ਸਕਦਾ ਹੈ।
ਗਲਤਫਹਮੀ: ਕੋਈ ਵੀ ਐਰਰ ਮਤਲਬ “ਸਾਈਟ ਡਾਊਨ ਹੈ,” ਅਤੇ redirects ਹਮੇਸ਼ਾ ਮੰਦੇ ਹਨ।
ਝਟਪਟ ਸੁਧਾਰ: ਸਟੇਟਸ ਕੋਡ ਸੰਕੇਤ ਹੁੰਦੇ ਹਨ:
ਗਲਤਫਹਮੀ: ਹਰ URL ਇੱਕ ਮਨੁੱਖ-ਪੜਨ ਯੋਗ ਪੇਜ਼ ਖੋਲ੍ਹੇ।
ਝਟਪਟ ਸੁਧਾਰ: ਇੱਕ URL ਡੇਟਾ (/api/orders), ਇੱਕ ਫਾਈਲ (/report.pdf), ਜਾਂ ਫਾਰਮ submisson ਲਈ ਐਕਸ਼ਨ ਐਂਡਪਾਇੰਟ ਨੂੰ ਨਿਸ਼ਾਨਾ ਕਰ ਸਕਦਾ ਹੈ।
ਗਲਤਫਹਮੀ: ਜੇ ਇਹ HTTPS ਹੈ ਤਾਂ ਸਾਈਟ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸੱਚੀ ਹੈ।
ਝਟਪਟ ਸੁਧਾਰ: HTTPS সংਪਰਕ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਡੋਮੇਨ ਨਾਲ ਜੁੜੇ ਹੋ—ਪਰ ਇਹ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਵਿਖਾਉਣ ਵਾਲਾ ਕਾਰੋਬਾਰ ਭਰੋਸੇਯੋਗ ਹੈ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ ਸਰੋਤ, ਸਮੱਗਰੀ ਅਤੇ ਪ੍ਰਸੰਗ ਦੀ ਠੀਕ-ਠਾਕ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
Tim Berners-Lee ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਸੋਚਣ ਵਿੱਚ ਹੈਲਕਾ ਸੀ: ਦਸਤਾਵੇਜ਼ਾਂ (ਅਤੇ ਫਿਰ ਐਪਲੀਕੇਸ਼ਨਾਂ) ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਐਡਰੈੱਸਿੰਗ ਸਕੀਮ, ਇੱਕ ਸਾਂਝਾ ਤਰੀਕਾ ਡੇਟਾ ਮੰਗਣ ਦੀ, ਅਤੇ ਇੱਕ ਸਾਂਝਾ ਫਾਰਮੈਟ ਜਿਸ ਨਾਲ ਉਹ ਦਰਸਾਏ ਅਤੇ ਲਿੰਕ ਕੀਤੇ ਜਾ ਸਕਣ, ਨਾਲ ਜੋੜੋ।
URL ਪਤਾ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਇਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ (ਅਕਸਰ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਉਸ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ)।
HTTP ਗੱਲਬਾਤ ਹੈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਨਿਯਮ ਹਨ (ਸਟੇਟਸ ਕੋਡ, ਹੈਡਰ, ਕੈਸ਼ਿੰਗ ਅਤੇ ਹੋਰ)।
HTML ਪੇਜ਼ ਫਾਰਮੈਟ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਸਮੱਗਰੀ ਰੇਂਡਰ ਹੋਵੇ—ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇਸ ਵਿੱਚ ਲਿੰਕ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਇਕ ਰਿਸੋਰਸ ਨੂੰ ਦੂਜੇ ਨਾਲ ਜੋੜਦੇ ਹਨ।
ਵੈੱਬ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਤਿੰਨ-ਕਦਮ ਲੂਪ ਵਾਂਗ ਸੋਚੋ:
ਇੱਕ ਵਾਰੀ ਇਹ ਲੂਪ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚ ਹੋਵੇ, ਆਧੁਨਿਕ ਵਿਸਥਾਰ (cookies, APIs, single-page apps, CDNs) ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆਉਂਦੇ ਹਨ: ਉਹ ਆਮ ਤੌਰ ਤੇ ਨਾਂ, ਮੰਗਣ ਜਾਂ ਰੇਂਡਰਿੰਗ ਦੇ ਸੁਧਾਰ ਹਨ।
ਇਨ੍ਹਾਂ ਬੁਨਿਆਦੀਆਂ ਨੂੰ ਸਮਝਣ ਨਾਲ ਤੁਰੰਤ ਲਾਭ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਵੈੱਬ ਟੂਲਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕੋਗੇ (“ਕੀ ਇਹ URLs ਅਤੇ ਮਿਆਰੀ HTTP 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ?”), ਵਿਕਾਸਕਾਰਾਂ ਨਾਲ ਬਹਿਤਰੀਨ ਸੰਚਾਰ ਕਰ ਸਕੋਗੇ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਸਮੱਸਿਆਵਾਂ ਜਿਵੇਂ ਟੁੱਟੇ ਲਿੰਕ, ਕੈਸ਼ਿੰਗ ਚੈਲੈਂਜ, ਜਾਂ “404 vs 500” ਦੀਆਂ ਗਲਤਫਹਮੀਆਂ ਨੂੰ ਸਾਫ਼ ਸਮਝ ਸਕੋਗੇ।
ਦੁਨੀਆ ਭਰ ਦਾ ਨੈੱਟਵਰਕ (ਰੂਟਰ, ਕੇਬਲ, IP ਰੂਟਿੰਗ) ਹੀ Internet ਹੈ ਜੋ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। Web ਉਸ ਤੇ ਚਲਣ ਵਾਲੀ ਇੱਕ ਸੇਵਾ ਹੈ: ਰਿਸੋਰਸਾਂ ਨੂੰ URLs ਨਾਲ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ, HTTP ਨਾਲ ਟਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਕਸਰ HTML ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ।
ਕਈ ਚੀਜ਼ਾਂ Intenet ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਪਰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ "Web" ਨਹੀਂ ਹੁੰਦੀਆਂ—ਜਿਵੇਂ ਕਿ ਈਮੇਲ, ਕੁਝ ਮਲਟੀਪਲੇਅਰ ਗੇਮ ਅਤੇ ਕਈ ਚੈਟ ਸਿਸਟਮ।
ਇੱਕ URL ਨੂੰ ਇੱਕ ਸਹੀ ਪਤਾ ਵਜੋਂ ਸੋਚੋ ਜੋ ਕਿਸੇ ਰਿਸੋਰਸ ਨੂੰ ਨਿਸ਼ਾਨਾ ਦਿੰਦਾ ਹੈ। ਇਹ HTML ਪੇਜ, ਤਸਵੀਰ, PDF ਜਾਂ API ਐਂਡਪਾਇੰਟ ਨੂੰ ਦਰਸਾ ਸਕਦਾ ਹੈ।
ਆਮ URL ਵਿੱਚ ਸ਼ਾਮِل ਹੁੰਦਾ ਹੈ:
ਇੱਕ ਡੋਮੇਨ (ਜਿਵੇਂ example.com) ਸਿਰਫ਼ ਹੋਸਟ ਦਾ ਨਾਮ ਹੁੰਦਾ ਹੈ। ਇੱਕ URL ਵਿੱਚ ਹੋਰ ਵੀ ਵੇਰਵੇ ਹੋ ਸਕਦੇ ਹਨ—ਜਿਵੇਂ path ਜਾਂ query—ਜੋ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਸਰਵਰ ਕੀ ਵਾਪਸ ਦੇਵੇਗਾ।
ਉਦਾਹਰਣ:
https://example.com/pricinghttps://example.com/search?q=shoesਫਰੈਗਮੈਂਟ (# ਤੋਂ ਬਾਅਦ ਵਾਲਾ ਹਿੱਸਾ) ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ HTTP ਰਿਕਵੇਸਟ ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਨਹੀਂ bheਜਿਆ ਜਾਂਦਾ।
ਆਮ ਵਰਤੋਂਾਂ:
#reviews)ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਫਰੈਗਮੈਂਟ ਬਦਲਣਾ ਪਏ ਤਾਂ ਅਕਸਰ ਪੂਰਾ ਪੇਜ਼ ਰੀਲੋਡ ਨਹੀਂ ਹੁੰਦਾ।
HTTP ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ-ਕਾਇਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ (ਬ੍ਰਾਊਜ਼ਰ/ਐਪ) ਅਤੇ ਸਰਵਰ ਦਰਮਿਆਨ ਰਿਕਵੇਸਟ-ਅਤੇ-ਰਿਸਪਾਂਸ ਦੀ ਗੱਲਬਾਤ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।
ਅਮਲ ਵਿੱਚ:
ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹੋ—ਜਿਵੇਂ ਕਿ ਪੇਜ਼ ਲੋਡ ਕਰਨਾ ਜਾਂ ਡੇਟਾ ਲੈਣਾ—ਤਾਂ GET ਵਰਤੋ। ਇਹ ਅਕਸਰ ਰੀਡ-ਓਨਲੀ ਮਨਿਆ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਲਈ ਡੇਟਾ ਭੇਜ ਰਹੇ ਹੋ—ਜਿਵੇਂ ਖਾਤਾ ਬਣਾਉਣਾ ਜਾਂ ਟਿੱਪਣੀ ਭੇਜਣਾ—ਤਾਂ POST ਵਰਤੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸੁਝਾਅ: ਜੇ ਕਾਰਵਾਈ ਬੁੱਕਮਾਰਕ/ਸ਼ੇਅਰ ਕਰਨ ਯੋਗ ਹੋਵੇ (ਜਿਵੇਂ ਇੱਕ ਖੋਜ), ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ GET ਠੀਕ ਰਹਿੰਦਾ ਹੈ; ਜੇ ਇਹ ਸਰਵਰ ਸਟੇਟ ਬਦਲਦਾ ਹੈ ਤਾਂ POST ਵਰਤੋਂ।
ਸਟੇਟਸ ਕੋਡ ਇੱਕ ਰਿਕਵੇਸਟ ਦੇ ਨਤੀਜੇ ਨੂੰ ਸੰਖੇਪ ਕਰਦੇ ਹਨ:
ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਵਿੱਚ, ਅਕਸਰ ਗਲਤ URL ਜਾਂ ਮਿਟਿਆ ਹੋਇਆ ਪੇਜ਼ ਦਿਖਾਉਂਦਾ ਹੈ; ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ-ਸਾਈਡ ਬੱਗ ਜਾਂ ਆਉਟੇਜ ਹੈ।
ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਰਵਰ ਨਾਲ ਜੁੜਨ ਲਈ ਇੱਕ IP ਪਤੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। DNS ਉਹ ਸਿਸਟਮ ਹੈ ਜੋ ਮਨੁੱਖੀ ਨਾਮ (ਜਿਵੇਂ example.com) ਨੂੰ IP ਪਤੇ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ।
ਜੇਕਰ ਕੋਈ ਸਾਈਟ ਕਦੇ-ਕਦੇ “resolve” ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ DNS ਇੱਕ ਆਮ ਸੰਦੇਹਯੋਗ ਕਾਰਣ ਹੁੰਦਾ ਹੈ—ਖਾਸਕਰ ਜੇ ਇਹ ਕਿਸੇ ਇਕ ਨੈੱਟਵਰਕ/ਡਿਵਾਈਸ 'ਤੇ ਫੇਲ ਹੋ ਰਿਹਾ ਹੋ ਪਰ ਦੂਜੇ 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੋਵੇ।
ਕੈਸ਼ਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਦੀਆਂ ਨਕਲਾਂ ਸੰਭਾਲ ਕੇ ਰੱਖਦਾ ਹੈ ਤਾਂ ਕਿ ਦੁਬਾਰਾ ਆਉਣ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਕਰ ਸਕੇ।
ਵਾਸਤਵਿਕ ਨਤੀਜੇ:
ਸਰਵਰ HTTP ਹੈਡਰਾਂ ਰਾਹੀਂ ਕੈਸ਼ਿੰਗ ਵਿਹਾਰ ਨੂੰ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕੈਸ਼ ਉਮਰ ਅਤੇ ਰੀਵੈਲਿਡੇਸ਼ਨ)।
HTTPS ਟਰੈਫਿਕ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਹੀਡੋਮੇਨ ਨਾਲ ਜੁੜੇ ਹੋ ਜੋ ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ, ਜਿਸ ਨਾਲ ਲੌਗਿਨ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ।
ਇਹ ਇਹ ਗੈਰਜ਼ਰੂਰੀ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਸਾਈਟ ਪੱਕੀ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਹੈ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ:
https) — ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈexample.com) — ਕਿਹੜਾ ਸਰਵਰ/products/shoes) — ਸਰਵਰ 'ਤੇ ਕਿਹੜਾ ਰਿਸੋਰਸ?color=black) — ਵਾਧੂ ਪੈਰਾਮੀਟਰ#reviews) — ਪੇਜ਼ ਦੇ ਅੰਦਰ ਇਕ ਸਥਾਨ (ਬ੍ਰਾਊਜ਼ਰ-ਸਾਈਡ)