ಲೇಖಕ: ಸರ್ ಟಿಮ್ ಬರ್ನರ್ಸ್-ಲೀ, URI ಗಳು, URL ಗಳು, HTTP, HTML ಮತ್ತು ವರ್ಲ್ಡ್ ವೈಡ್ ವೆಬ್ ಮತ್ತು W3C ಯ ಪ್ರಸ್ತುತ ಮುಖ್ಯಸ್ಥ. 1998 ರಲ್ಲಿ ಬರೆದ ಲೇಖನ

ಯಾವ URI ಅನ್ನು "ತಂಪು" ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ?
ಬದಲಾಗದ ಒಂದು.
URI ಗಳು ಹೇಗೆ ಬದಲಾಗುತ್ತವೆ?
URI ಗಳು ಬದಲಾಗುವುದಿಲ್ಲ: ಜನರು ಅವುಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ.

ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಜನರು URI ಗಳನ್ನು ಬದಲಾಯಿಸಲು (ಅಥವಾ ದಾಖಲೆಗಳನ್ನು ಬೆಂಬಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಲು) ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅವುಗಳಲ್ಲಿ ಲಕ್ಷಾಂತರ ಇವೆ.

ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಡೊಮೇನ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನ ನಾಮಮಾತ್ರದ ಮಾಲೀಕರು ವಾಸ್ತವವಾಗಿ ಡೊಮೇನ್ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಆದ್ದರಿಂದ ಅದರಲ್ಲಿರುವ ಎಲ್ಲಾ URI ಗಳು. ದಿವಾಳಿತನದ ಹೊರತಾಗಿ, ಡೊಮೇನ್ ಹೆಸರಿನ ಮಾಲೀಕರು ಹೆಸರನ್ನು ಇಡುವುದರಿಂದ ಏನೂ ತಡೆಯುವುದಿಲ್ಲ. ಮತ್ತು ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ನಿಮ್ಮ ಡೊಮೇನ್ ಹೆಸರಿನಲ್ಲಿರುವ URI ಸ್ಥಳವು ಸಂಪೂರ್ಣವಾಗಿ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ನೀವು ಇಷ್ಟಪಡುವಷ್ಟು ಸ್ಥಿರಗೊಳಿಸಬಹುದು. ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಡಾಕ್ಯುಮೆಂಟ್ ಕಣ್ಮರೆಯಾಗಲು ಉತ್ತಮ ಕಾರಣವೆಂದರೆ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಹೊಂದಿರುವ ಕಂಪನಿಯು ವ್ಯವಹಾರದಿಂದ ಹೊರಗುಳಿದಿದೆ ಅಥವಾ ಸರ್ವರ್ ಅನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಹಾಗಾದರೆ ಜಗತ್ತಿನಲ್ಲಿ ಏಕೆ ಕಾಣೆಯಾದ ಲಿಂಕ್‌ಗಳಿವೆ? ಇವುಗಳಲ್ಲಿ ಕೆಲವು ಕೇವಲ ಮುಂದಾಲೋಚನೆಯ ಕೊರತೆ. ನೀವು ಕೇಳಬಹುದಾದ ಕೆಲವು ಕಾರಣಗಳು ಇಲ್ಲಿವೆ:

ನಾವು ಅದನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಸೈಟ್ ಅನ್ನು ಮರುಸಂಘಟಿಸಿದ್ದೇವೆ.

ಹಳೆಯ URI ಗಳು ಇನ್ನು ಮುಂದೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ನಿಜವಾಗಿಯೂ ಭಾವಿಸುತ್ತೀರಾ? ಹಾಗಿದ್ದಲ್ಲಿ, ನೀವು ಅವರನ್ನು ತುಂಬಾ ಕಳಪೆಯಾಗಿ ಆರಿಸಿದ್ದೀರಿ. ಮುಂದಿನ ಮರುವಿನ್ಯಾಸಕ್ಕಾಗಿ ಹೊಸದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದನ್ನು ಪರಿಗಣಿಸಿ.

ಯಾವುದು ಹಳೆಯದು, ಯಾವುದು ಗೌಪ್ಯವಾಗಿದೆ ಮತ್ತು ಇನ್ನೂ ಸಂಬಂಧಿತವಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಹಲವು ಸಂಗತಿಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಎಲ್ಲವನ್ನೂ ಆಫ್ ಮಾಡುವುದು ಉತ್ತಮ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ.

ನಾನು ಸಹಾನುಭೂತಿ ಮಾತ್ರ ಮಾಡಬಹುದು. W3C ನಾವು ಸಾರ್ವಜನಿಕಗೊಳಿಸುವ ಮೊದಲು ಗೌಪ್ಯತೆಗಾಗಿ ಆರ್ಕೈವಲ್ ವಸ್ತುಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಶೋಧಿಸಬೇಕಾದ ಅವಧಿಯನ್ನು ಎದುರಿಸಿತು. ನಿರ್ಧಾರವನ್ನು ಮುಂಚಿತವಾಗಿ ಯೋಚಿಸಬೇಕು - ಪ್ರತಿ ಡಾಕ್ಯುಮೆಂಟ್‌ನೊಂದಿಗೆ ನೀವು ಸ್ವೀಕಾರಾರ್ಹ ಓದುಗರ ಸಂಖ್ಯೆ, ರಚನೆ ದಿನಾಂಕ ಮತ್ತು ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಮುಕ್ತಾಯ ದಿನಾಂಕವನ್ನು ದಾಖಲಿಸುತ್ತೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಈ ಮೆಟಾಡೇಟಾವನ್ನು ಉಳಿಸಿ.

ಸರಿ, ನಾವು ಫೈಲ್‌ಗಳನ್ನು ಸರಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ...

ಇದು ಅತ್ಯಂತ ಕರುಣಾಜನಕ ಮನ್ನಿಸುವಿಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಆಬ್ಜೆಕ್ಟ್‌ನ URI ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅದರ ನಿಜವಾದ ಸ್ಥಳದ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ನಿಯಂತ್ರಿಸಲು ವೆಬ್ ಸರ್ವರ್‌ಗಳು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ ಎಂದು ಅನೇಕ ಜನರಿಗೆ ತಿಳಿದಿಲ್ಲ. URI ಜಾಗವನ್ನು ಒಂದು ಅಮೂರ್ತ ಸ್ಥಳವೆಂದು ಯೋಚಿಸಿ, ಸಂಪೂರ್ಣವಾಗಿ ಸಂಘಟಿತವಾಗಿದೆ. ನಂತರ ನೀವು ನಿಜವಾಗಿ ಅದನ್ನು ಅರಿತುಕೊಳ್ಳಲು ಬಳಸುವ ಯಾವುದೇ ವಾಸ್ತವತೆಗೆ ಮ್ಯಾಪಿಂಗ್ ಮಾಡಿ. ನಂತರ ಇದನ್ನು ವೆಬ್ ಸರ್ವರ್‌ಗೆ ವರದಿ ಮಾಡಿ. ಅದನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯಲು ನಿಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್ ತುಣುಕನ್ನು ಸಹ ನೀವು ಬರೆಯಬಹುದು.

ಜಾನ್ ಇನ್ನು ಮುಂದೆ ಈ ಫೈಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಜೇನ್ ಈಗ ನಿರ್ವಹಿಸುತ್ತಾನೆ.

URI ಯಲ್ಲಿ ಜಾನ್ ಹೆಸರಿದೆಯೇ? ಇಲ್ಲ, ಫೈಲ್ ಅವನ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿದೆಯೇ? ಸರಿ, ಸರಿ.

ಈ ಹಿಂದೆ ನಾವು ಇದಕ್ಕಾಗಿ CGI ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೆವು, ಆದರೆ ಈಗ ನಾವು ಬೈನರಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ರಚಿಸಲಾದ ಪುಟಗಳು "cgibin" ಅಥವಾ "cgi" ಪ್ರದೇಶದಲ್ಲಿ ನೆಲೆಗೊಂಡಿರಬೇಕು ಎಂಬ ಹುಚ್ಚು ಕಲ್ಪನೆಯಿದೆ. ನಿಮ್ಮ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ನೀವು ಹೇಗೆ ಚಲಾಯಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೆಕ್ಯಾನಿಕ್ಸ್ ಅನ್ನು ಇದು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ನೀವು ಕಾರ್ಯವಿಧಾನವನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಿ (ವಿಷಯವನ್ನು ಉಳಿಸುವಾಗಲೂ ಸಹ), ಮತ್ತು ಓಹ್ - ನಿಮ್ಮ ಎಲ್ಲಾ URIಗಳು ಬದಲಾಗುತ್ತವೆ.

ಉದಾಹರಣೆಗೆ ರಾಷ್ಟ್ರೀಯ ವಿಜ್ಞಾನ ಪ್ರತಿಷ್ಠಾನವನ್ನು (NSF) ತೆಗೆದುಕೊಳ್ಳಿ:

NSF ಆನ್‌ಲೈನ್ ದಾಖಲೆಗಳು

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲ ಪುಟವು ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ. cgi-bin, oldbrowse и pl - ಇದೆಲ್ಲವೂ ನಾವು ಈಗ ಅದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಹುಡುಕಲು ನೀವು ಪುಟವನ್ನು ಬಳಸಿದರೆ, ನೀವು ಪಡೆಯುವ ಮೊದಲ ಫಲಿತಾಂಶವು ಅಷ್ಟೇ ಕೆಟ್ಟದ್ದಾಗಿರುತ್ತದೆ:

ಕ್ರಿಪ್ಟೋಲಜಿ ಮತ್ತು ಕೋಡಿಂಗ್ ಥಿಯರಿ ಮೇಲೆ ವರ್ಕಿಂಗ್ ಗ್ರೂಪ್ ವರದಿ

http://www.nsf.gov/cgi-bin/getpub?nsf9814

ಡಾಕ್ಯುಮೆಂಟ್ ಸೂಚ್ಯಂಕ ಪುಟಕ್ಕಾಗಿ, html ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ವತಃ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

ಇಲ್ಲಿ ಪಬ್‌ಗಳು/1998 ಹೆಡರ್ ಯಾವುದೇ ಭವಿಷ್ಯದ ಆರ್ಕೈವಲ್ ಸೇವೆಗೆ ಹಳೆಯ 1998 ಡಾಕ್ಯುಮೆಂಟ್ ವರ್ಗೀಕರಣ ಯೋಜನೆಯು ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ಉತ್ತಮ ಸುಳಿವು ನೀಡುತ್ತದೆ. 2098 ರಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಸಂಖ್ಯೆಗಳು ವಿಭಿನ್ನವಾಗಿ ಕಂಡುಬಂದರೂ, ಈ URI ಇನ್ನೂ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ ಮತ್ತು NSF ಅಥವಾ ಆರ್ಕೈವ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಯಾವುದೇ ಇತರ ಸಂಸ್ಥೆಗಳೊಂದಿಗೆ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಊಹಿಸುತ್ತೇನೆ.

URL ಗಳು ನಿರಂತರವಾಗಿರಬೇಕು ಎಂದು ನಾನು ಭಾವಿಸಿರಲಿಲ್ಲ - URN ಗಳು ಇದ್ದವು.

ಇದು ಬಹುಶಃ URN ಚರ್ಚೆಯ ಕೆಟ್ಟ ಅಡ್ಡಪರಿಣಾಮಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಹೆಚ್ಚು ಶಾಶ್ವತ ನೇಮ್‌ಸ್ಪೇಸ್‌ನ ಸಂಶೋಧನೆಯ ಕಾರಣ, ಅವರು ತೂಗಾಡುವ ಲಿಂಕ್‌ಗಳ ಬಗ್ಗೆ ಅಸಡ್ಡೆ ಹೊಂದಿರಬಹುದು ಎಂದು ಕೆಲವರು ಭಾವಿಸುತ್ತಾರೆ ಏಕೆಂದರೆ "URN ಗಳು ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತವೆ." ನೀವು ಈ ಜನರಲ್ಲಿ ಒಬ್ಬರಾಗಿದ್ದರೆ, ನಾನು ನಿಮ್ಮನ್ನು ನಿರಾಶೆಗೊಳಿಸುತ್ತೇನೆ.

ನಾನು ನೋಡಿದ ಹೆಚ್ಚಿನ URN ಸ್ಕೀಮ್‌ಗಳು ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ದಿನಾಂಕ ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ ಅಥವಾ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಅನುಸರಿಸುವ ಅಧಿಕಾರ ಗುರುತಿಸುವಿಕೆಯಂತೆ ಕಾಣುತ್ತವೆ. ಇದು HTTP URI ಗೆ ಹೋಲುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಿಮ್ಮ ಸಂಸ್ಥೆಯು ದೀರ್ಘಾವಧಿಯ URN ಗಳನ್ನು ರಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ, ನಿಮ್ಮ HTTP URI ಗಳಿಗಾಗಿ ಅವುಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ ಅದನ್ನು ಈಗ ಸಾಬೀತುಪಡಿಸಿ. HTTP ಯಲ್ಲಿಯೇ ನಿಮ್ಮ URI ಅನ್ನು ಅಸ್ಥಿರಗೊಳಿಸುವ ಯಾವುದೂ ಇಲ್ಲ. ನಿಮ್ಮ ಸಂಸ್ಥೆ ಮಾತ್ರ. ಪ್ರಸ್ತುತ ಫೈಲ್ ಹೆಸರಿಗೆ ಡಾಕ್ಯುಮೆಂಟ್ URN ಅನ್ನು ಮ್ಯಾಪ್ ಮಾಡುವ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಹಿಂಪಡೆಯಲು ವೆಬ್ ಸರ್ವರ್ ಅದನ್ನು ಬಳಸಲು ಅನುಮತಿಸಿ.

ನೀವು ಈ ಹಂತವನ್ನು ತಲುಪಿದ್ದರೆ, ಕೆಲವು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಿಮಗೆ ಸಮಯ, ಹಣ ಮತ್ತು ಸಂಪರ್ಕಗಳು ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಈ ಕೆಳಗಿನ ಕ್ಷಮೆಯನ್ನು ಹೇಳಬಹುದು:

ನಾವು ಬಯಸಿದ್ದೇವೆ, ಆದರೆ ನಮ್ಮ ಬಳಿ ಸರಿಯಾದ ಪರಿಕರಗಳಿಲ್ಲ.

ಆದರೆ ನೀವು ಇದರೊಂದಿಗೆ ಸಹಾನುಭೂತಿ ಹೊಂದಬಹುದು. ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಒಪ್ಪುತ್ತೇನೆ. ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ತಕ್ಷಣವೇ ನಿರಂತರವಾದ URI ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಮತ್ತು ಪ್ರಸ್ತುತ ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಕ್ರೇಜಿ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಎಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆಯೋ ಅಲ್ಲೆಲ್ಲಾ ಅದನ್ನು ಹಿಂತಿರುಗಿಸಲು ಒತ್ತಾಯಿಸುವುದು. ನೀವು ಎಲ್ಲಾ URI ಗಳನ್ನು ಚೆಕ್ ಆಗಿ ಫೈಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ನವೀಕೃತವಾಗಿರಿಸಿಕೊಳ್ಳಿ. ಒಂದೇ ಡಾಕ್ಯುಮೆಂಟ್‌ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಅನುವಾದಗಳ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ನೀವು ಸಂರಕ್ಷಿಸಲು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಆಕಸ್ಮಿಕ ದೋಷದಿಂದ ಫೈಲ್ ದೋಷಪೂರಿತವಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ವತಂತ್ರ ಚೆಕ್‌ಸಮ್ ದಾಖಲೆಯನ್ನು ನಿರ್ವಹಿಸಿ. ಮತ್ತು ವೆಬ್ ಸರ್ವರ್‌ಗಳು ಈ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಪೆಟ್ಟಿಗೆಯಿಂದ ಹೊರಬರುವುದಿಲ್ಲ. ನೀವು ಹೊಸ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ರಚಿಸಲು ಬಯಸಿದಾಗ, ನಿಮ್ಮ ಸಂಪಾದಕರು URI ಅನ್ನು ಸೂಚಿಸಲು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತಾರೆ.

URI ಅನ್ನು ಬದಲಾಯಿಸದೆಯೇ URI ಜಾಗದಲ್ಲಿ ಮಾಲೀಕತ್ವ, ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರವೇಶ, ಆರ್ಕೈವ್ ಮಟ್ಟದ ಭದ್ರತೆ ಇತ್ಯಾದಿಗಳನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಇದು ತುಂಬಾ ಕೆಟ್ಟದು. ಆದರೆ ನಾವು ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ. W3C ನಲ್ಲಿ, ನಾವು ಆವೃತ್ತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಜಿಗೆಡಿಟ್ (ಜಿಗ್ಸಾ ಎಡಿಟಿಂಗ್ ಸರ್ವರ್) ಕಾರ್ಯವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಡಾಕ್ಯುಮೆಂಟ್ ಉತ್ಪಾದನೆಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಪ್ರಯೋಗಿಸುತ್ತೇವೆ. ನೀವು ಪರಿಕರಗಳು, ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರೆ, ಈ ಸಮಸ್ಯೆಗೆ ಗಮನ ಕೊಡಿ!

ಈ ಕ್ಷಮಿಸಿ ಇದು ಸೇರಿದಂತೆ ಅನೇಕ W3C ಪುಟಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ: ಆದ್ದರಿಂದ ನಾನು ಹೇಳಿದಂತೆ ಮಾಡು, ನಾನು ಮಾಡುವಂತೆ ಅಲ್ಲ.

ನಾನು ಯಾಕೆ ಕಾಳಜಿ ವಹಿಸಬೇಕು?

ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ ನೀವು URI ಅನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಹಳೆಯ URI ಗೆ ಯಾರು ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇವು ಸಾಮಾನ್ಯ ವೆಬ್ ಪುಟಗಳಿಂದ ಲಿಂಕ್‌ಗಳಾಗಿರಬಹುದು. ನಿಮ್ಮ ಪುಟವನ್ನು ಬುಕ್‌ಮಾರ್ಕ್ ಮಾಡಿ. ಸ್ನೇಹಿತರಿಗೆ ಬರೆದ ಪತ್ರದ ಅಂಚುಗಳಲ್ಲಿ URI ಅನ್ನು ಸ್ಕ್ರಾಲ್ ಮಾಡಿರಬಹುದು.

ಯಾರಾದರೂ ಲಿಂಕ್ ಅನ್ನು ಅನುಸರಿಸಿದಾಗ ಮತ್ತು ಅದು ಮುರಿದುಹೋದಾಗ, ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ಮಾಲೀಕರ ಮೇಲಿನ ನಂಬಿಕೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಅವನು ತನ್ನ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಗದೆ ಭಾವನಾತ್ಮಕವಾಗಿ ಮತ್ತು ದೈಹಿಕವಾಗಿ ನಿರಾಶೆಗೊಂಡಿದ್ದಾನೆ.

ಬಹಳಷ್ಟು ಜನರು ಸಾರ್ವಕಾಲಿಕ ಮುರಿದ ಲಿಂಕ್‌ಗಳ ಬಗ್ಗೆ ದೂರು ನೀಡುತ್ತಾರೆ ಮತ್ತು ಹಾನಿ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಡಾಕ್ಯುಮೆಂಟ್ ಕಣ್ಮರೆಯಾದ ಸರ್ವರ್‌ನ ನಿರ್ವಾಹಕರಿಗೆ ಪ್ರತಿಷ್ಠಿತ ಹಾನಿ ಸಹ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಹಾಗಾದರೆ ನಾನು ಏನು ಮಾಡಬೇಕು? URI ವಿನ್ಯಾಸ

2 ವರ್ಷಗಳಲ್ಲಿ, 20 ವರ್ಷಗಳಲ್ಲಿ, 200 ವರ್ಷಗಳಲ್ಲಿ ಬಳಸಬಹುದಾದ URI ಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ವೆಬ್‌ಮಾಸ್ಟರ್‌ನ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ. ಇದಕ್ಕೆ ಚಿಂತನಶೀಲತೆ, ಸಂಘಟನೆ ಮತ್ತು ನಿರ್ಣಯದ ಅಗತ್ಯವಿದೆ.

ಅವುಗಳಲ್ಲಿನ ಯಾವುದೇ ಮಾಹಿತಿ ಬದಲಾದರೆ URIಗಳು ಬದಲಾಗುತ್ತವೆ. ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೀರಿ ಎಂಬುದು ಬಹಳ ಮುಖ್ಯ. (ಏನು, URI ವಿನ್ಯಾಸ? ನಾನು URI ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕೇ? ಹೌದು, ನೀವು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು). ವಿನ್ಯಾಸವು ಮೂಲಭೂತವಾಗಿ URI ಯಲ್ಲಿ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ ಎಂದರ್ಥ.

ಡಾಕ್ಯುಮೆಂಟ್ ರಚಿಸಿದ ದಿನಾಂಕ - URI ನೀಡಿದ ದಿನಾಂಕ - ಇದು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಹಳೆಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವ ಪ್ರಶ್ನೆಗಳಿಂದ ಹೊಸ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಇದು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದೆ. URI ಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ಇದು ಉತ್ತಮ ಸ್ಥಳವಾಗಿದೆ. ಡಾಕ್ಯುಮೆಂಟ್ ದಿನಾಂಕವಾಗಿದ್ದರೆ, ಭವಿಷ್ಯದಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರಸ್ತುತವಾಗಿದ್ದರೂ ಸಹ, ಇದು ಉತ್ತಮ ಆರಂಭವಾಗಿದೆ.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ "ಇತ್ತೀಚಿನ" ಆವೃತ್ತಿಯಾಗಿರುವ ಪುಟವು ಕೇವಲ ಒಂದು ಅಪವಾದವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ಇಡೀ ಸಂಸ್ಥೆಗೆ ಅಥವಾ ಅದರ ದೊಡ್ಡ ಭಾಗಕ್ಕೆ.

http://www.pathfinder.com/money/moneydaily/latest/

ಇದು ಮನಿ ಮ್ಯಾಗಜೀನ್‌ನ ಇತ್ತೀಚಿನ ಮನಿ ಡೈಲಿ ಅಂಕಣವಾಗಿದೆ. ಈ URI ನಲ್ಲಿ ದಿನಾಂಕದ ಅಗತ್ಯವಿಲ್ಲದಿರುವ ಮುಖ್ಯ ಕಾರಣವೆಂದರೆ ಲಾಗ್ ಅನ್ನು ಮೀರಿಸುವ URI ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ. ಮನಿ ಮಾಯವಾದಾಗ ಮನಿ ಡೈಲಿ ಎಂಬ ಪರಿಕಲ್ಪನೆ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನೀವು ವಿಷಯಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಲು ಬಯಸಿದರೆ, ಆರ್ಕೈವ್‌ನಲ್ಲಿ ನೀವು ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಲಿಂಕ್ ಮಾಡಬೇಕು:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ. "ಹಣ" ಎಂಬುದು pathfinder.com ನ ಜೀವನದುದ್ದಕ್ಕೂ ಒಂದೇ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ. "98" ನಕಲು ಮತ್ತು ಅನಗತ್ಯವಾದ ".html" ಇದೆ, ಆದರೆ ಇದು ಬಲವಾದ URI ನಂತೆ ಕಾಣುತ್ತದೆ.

ಯಾವುದನ್ನು ಬಿಟ್ಟುಬಿಡಬೇಕು

ಎಲ್ಲಾ! ರಚನೆಯ ದಿನಾಂಕದ ಹೊರತಾಗಿ, URI ನಲ್ಲಿ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ಹಾಕುವುದು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ತೊಂದರೆಯನ್ನು ಕೇಳುತ್ತಿದೆ.

ಲೇಖಕರ ಹೆಸರು. ಹೊಸ ಆವೃತ್ತಿಗಳು ಲಭ್ಯವಾಗುತ್ತಿದ್ದಂತೆ ಕರ್ತೃತ್ವವು ಬದಲಾಗಬಹುದು. ಜನರು ಸಂಸ್ಥೆಗಳನ್ನು ತೊರೆದು ಇತರರಿಗೆ ವಿಷಯಗಳನ್ನು ರವಾನಿಸುತ್ತಾರೆ.
ವಿಷಯ. ಇದು ತುಂಬಾ ಕಷ್ಟ. ಇದು ಯಾವಾಗಲೂ ಮೊದಲಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಆಶ್ಚರ್ಯಕರವಾಗಿ ತ್ವರಿತವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ನಾನು ಇದರ ಬಗ್ಗೆ ಹೆಚ್ಚು ಕೆಳಗೆ ಮಾತನಾಡುತ್ತೇನೆ.
ಸ್ಥಿತಿ. "ಹಳೆಯ", "ಡ್ರಾಫ್ಟ್" ಮತ್ತು ಮುಂತಾದ ಡೈರೆಕ್ಟರಿಗಳು, "ಇತ್ತೀಚಿನ" ಮತ್ತು "ಕೂಲ್" ಅನ್ನು ನಮೂದಿಸಬಾರದು, ಎಲ್ಲಾ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ದಾಖಲೆಗಳು ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ - ಇಲ್ಲದಿದ್ದರೆ ಕರಡುಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಡಾಕ್ಯುಮೆಂಟ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ಅದರ ಸ್ಥಿತಿಯನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ನಿರಂತರ ಗುರುತಿಸುವಿಕೆಯ ಅಗತ್ಯವಿದೆ. ಸ್ಥಿತಿಯನ್ನು ಹೆಸರಿನಿಂದ ಹೊರಗಿಡಿ.
ಪ್ರವೇಶ. W3C ನಲ್ಲಿ, ನಾವು ಉದ್ಯೋಗಿಗಳು, ಸದಸ್ಯರು ಮತ್ತು ಸಾರ್ವಜನಿಕರಿಗಾಗಿ ಸೈಟ್ ಅನ್ನು ವಿಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇವೆ. ಇದು ಒಳ್ಳೆಯದು ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಸಹಜವಾಗಿ, ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಸಿಬ್ಬಂದಿಯಿಂದ ತಂಡದ ಕಲ್ಪನೆಗಳಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಸದಸ್ಯರೊಂದಿಗೆ ಚರ್ಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಸಾರ್ವಜನಿಕ ಜ್ಞಾನವಾಗುತ್ತದೆ. ಪ್ರತಿ ಬಾರಿ ವಿಶಾಲ ಚರ್ಚೆಗಾಗಿ ಡಾಕ್ಯುಮೆಂಟ್ ತೆರೆದಾಗ, ಅದರ ಎಲ್ಲಾ ಹಳೆಯ ಲಿಂಕ್‌ಗಳು ಮುರಿದುಹೋದರೆ ಅದು ನಿಜಕ್ಕೂ ನಾಚಿಕೆಗೇಡಿನ ಸಂಗತಿ! ಈಗ ನಾವು ಸರಳ ದಿನಾಂಕ ಕೋಡ್‌ಗೆ ಹೋಗುತ್ತೇವೆ.
ಫೈಲ್ ವಿಸ್ತರಣೆ. ಬಹಳ ಸಾಮಾನ್ಯವಾದ ಘಟನೆ. "cgi", ".html" ಕೂಡ ಭವಿಷ್ಯದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ. ನೀವು 20 ವರ್ಷಗಳಲ್ಲಿ ಈ ಪುಟಕ್ಕಾಗಿ HTML ಅನ್ನು ಬಳಸದೇ ಇರಬಹುದು, ಆದರೆ ಅದಕ್ಕೆ ಇಂದಿನ ಲಿಂಕ್‌ಗಳು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. W3C ಸೈಟ್‌ನಲ್ಲಿ ಅಂಗೀಕೃತ ಲಿಂಕ್‌ಗಳು ವಿಸ್ತರಣೆಯನ್ನು ಬಳಸುವುದಿಲ್ಲ (ಅದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗಿದೆ).
ಸಾಫ್ಟ್ವೇರ್ ಕಾರ್ಯವಿಧಾನಗಳು. URI ನಲ್ಲಿ, "cgi", "exec" ಮತ್ತು "ನಾವು ಯಾವ ಸಾಫ್ಟ್‌ವೇರ್ ಬಳಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡಿ" ಎಂದು ಕಿರುಚುವ ಇತರ ಪದಗಳನ್ನು ನೋಡಿ. ಯಾರಾದರೂ ತಮ್ಮ ಇಡೀ ಜೀವನವನ್ನು ಪರ್ಲ್ ಸಿಜಿಐ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ಬಯಸುತ್ತಾರೆಯೇ? ಇಲ್ಲವೇ? ನಂತರ .pl ವಿಸ್ತರಣೆಯನ್ನು ತೆಗೆದುಹಾಕಿ. ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಸರ್ವರ್ ಕೈಪಿಡಿಯನ್ನು ಓದಿ.
ಡಿಸ್ಕ್ ಹೆಸರು. ಬನ್ನಿ! ಆದರೆ ನಾನು ಇದನ್ನು ನೋಡಿದ್ದೇನೆ.

ಆದ್ದರಿಂದ ನಮ್ಮ ಸೈಟ್‌ನಿಂದ ಉತ್ತಮ ಉದಾಹರಣೆ ಸರಳವಾಗಿದೆ

http://www.w3.org/1998/12/01/chairs

... W3C ಚೇರ್ಸ್ ಸಭೆಯ ನಿಮಿಷಗಳ ವರದಿ.

ವಿಷಯದ ಪ್ರಕಾರ ವಿಷಯಗಳು ಮತ್ತು ವರ್ಗೀಕರಣ

ನಾನು ಈ ಅಪಾಯದ ಬಗ್ಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೇಳುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದು ತಪ್ಪಿಸಲು ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ವಿಷಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ನಿಮ್ಮ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಅವರು ಮಾಡುವ ಕೆಲಸದ ಮೂಲಕ ವರ್ಗೀಕರಿಸಿದಾಗ ವಿಷಯಗಳು URI ಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಆದರೆ ಈ ಸ್ಥಗಿತವು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ. ಪ್ರದೇಶಗಳ ಹೆಸರುಗಳು ಬದಲಾಗುತ್ತವೆ. W3C ನಲ್ಲಿ ನಾವು ಮಾರ್ಕ್‌ಅಪ್ ಅನ್ನು ಮಾರ್ಕಪ್‌ಗೆ ಮತ್ತು ನಂತರ HTML ಗೆ ವಿಭಾಗದ ನಿಜವಾದ ವಿಷಯವನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು ಬಯಸಿದ್ದೇವೆ. ಇದರ ಜೊತೆಗೆ, ಆಗಾಗ್ಗೆ ಸಮತಟ್ಟಾದ ನೇಮ್‌ಸ್ಪೇಸ್ ಇರುತ್ತದೆ. 100 ವರ್ಷಗಳಲ್ಲಿ, ನೀವು ಏನನ್ನೂ ಮರುಬಳಕೆ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ನಿಮಗೆ ಖಚಿತವಾಗಿದೆಯೇ? ನಮ್ಮ ಚಿಕ್ಕ ಜೀವನದಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ "ಇತಿಹಾಸ" ಮತ್ತು "ಸ್ಟೈಲ್ ಶೀಟ್‌ಗಳನ್ನು" ಮರುಬಳಕೆ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ.

ಇದು ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಪ್ರಲೋಭನಗೊಳಿಸುವ ಮಾರ್ಗವಾಗಿದೆ-ಮತ್ತು ಸಂಪೂರ್ಣ ವೆಬ್ ಸೇರಿದಂತೆ ಯಾವುದನ್ನಾದರೂ ಸಂಘಟಿಸಲು ನಿಜವಾದ ಪ್ರಲೋಭನಕಾರಿ ಮಾರ್ಗವಾಗಿದೆ. ಇದು ಉತ್ತಮ ಮಧ್ಯಮ-ಅವಧಿಯ ಪರಿಹಾರವಾಗಿದೆ ಆದರೆ ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಗಂಭೀರ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ.

ಕಾರಣದ ಭಾಗವು ಅರ್ಥದ ತತ್ವಶಾಸ್ತ್ರದಲ್ಲಿದೆ. ಭಾಷೆಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಪದವು ಕ್ಲಸ್ಟರಿಂಗ್‌ಗೆ ಸಂಭಾವ್ಯ ಗುರಿಯಾಗಿದೆ, ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಯು ಅದರ ಅರ್ಥದ ಬಗ್ಗೆ ವಿಭಿನ್ನ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರಬಹುದು. ಘಟಕಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳು ಮರಕ್ಕಿಂತ ವೆಬ್‌ನಂತೆಯೇ ಇರುವುದರಿಂದ, ವೆಬ್‌ನೊಂದಿಗೆ ಒಪ್ಪುವವರೂ ಸಹ ಮರದ ವಿಭಿನ್ನ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಇವುಗಳು ಸಾಮಾನ್ಯ ಪರಿಹಾರವಾಗಿ ಕ್ರಮಾನುಗತ ವರ್ಗೀಕರಣದ ಅಪಾಯಗಳ ಬಗ್ಗೆ ನನ್ನ (ಹೆಚ್ಚಾಗಿ ಪುನರಾವರ್ತಿತ) ಸಾಮಾನ್ಯ ಅವಲೋಕನಗಳಾಗಿವೆ.

ವಾಸ್ತವವಾಗಿ, ನೀವು URI ನಲ್ಲಿ ವಿಷಯದ ಹೆಸರನ್ನು ಬಳಸಿದಾಗ, ನೀವು ಕೆಲವು ರೀತಿಯ ವರ್ಗೀಕರಣಕ್ಕೆ ನಿಮ್ಮನ್ನು ಬದ್ಧರಾಗುತ್ತೀರಿ. ಬಹುಶಃ ಭವಿಷ್ಯದಲ್ಲಿ ನೀವು ಬೇರೆ ಆಯ್ಕೆಯನ್ನು ಬಯಸುತ್ತೀರಿ. URI ನಂತರ ಉಲ್ಲಂಘನೆಗೆ ಒಳಗಾಗುತ್ತದೆ.

URI ನ ಭಾಗವಾಗಿ ವಿಷಯದ ಪ್ರದೇಶವನ್ನು ಬಳಸುವ ಕಾರಣವೆಂದರೆ URI ಜಾಗದ ಉಪವಿಭಾಗಗಳ ಜವಾಬ್ದಾರಿಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ನಿಮಗೆ ಸಾಂಸ್ಥಿಕ ದೇಹದ ಹೆಸರು ಬೇಕಾಗುತ್ತದೆ - ಇಲಾಖೆ, ಗುಂಪು ಅಥವಾ ಯಾವುದಾದರೂ - ಅದು ಆ ಉಪಸ್ಥಳಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಇದು ಸಾಂಸ್ಥಿಕ ರಚನೆಗೆ URI ಬೈಂಡಿಂಗ್ ಆಗಿದೆ. ಮುಂದಿನ (ಎಡ) URI ಅನ್ನು ದಿನಾಂಕದಿಂದ ಸಂರಕ್ಷಿಸಿದರೆ ಮಾತ್ರ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ: 1998/pics ನಿಮ್ಮ ಸರ್ವರ್‌ಗೆ "1998 ರಲ್ಲಿ ನಾವು ಚಿತ್ರಗಳೊಂದಿಗೆ ಏನನ್ನು ಅರ್ಥೈಸಿದ್ದೇವೆ" ಎಂಬುದಕ್ಕಿಂತ "1998 ರಲ್ಲಿ ನಾವು ಈಗ ಚಿತ್ರಗಳು ಎಂದು ಕರೆಯುವ ಮೂಲಕ ಏನು ಮಾಡಿದ್ದೇವೆ" ಎಂದು ಅರ್ಥೈಸಬಹುದು.

ಡೊಮೇನ್ ಹೆಸರನ್ನು ಮರೆಯಬೇಡಿ

ಇದು URI ನಲ್ಲಿನ ಮಾರ್ಗಕ್ಕೆ ಮಾತ್ರವಲ್ಲ, ಸರ್ವರ್ ಹೆಸರಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ನೀವು ವಿಭಿನ್ನ ವಿಷಯಗಳಿಗಾಗಿ ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅನೇಕ, ಅನೇಕ ಲಿಂಕ್‌ಗಳನ್ನು ನಾಶಪಡಿಸದೆ ಈ ವಿಭಾಗವನ್ನು ಬದಲಾಯಿಸುವುದು ಅಸಾಧ್ಯವೆಂದು ನೆನಪಿಡಿ. ಕೆಲವು ಕ್ಲಾಸಿಕ್ "ನಾವು ಇಂದು ಬಳಸುವ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನೋಡಿ" ತಪ್ಪುಗಳು ಡೊಮೇನ್ ಹೆಸರುಗಳು "cgi.pathfinder.com", "secure", "lists.w3.org". ಸರ್ವರ್ ಆಡಳಿತವನ್ನು ಸುಲಭಗೊಳಿಸಲು ಅವುಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಡೊಮೇನ್ ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿನ ವಿಭಾಗ, ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ಥಿತಿ, ಪ್ರವೇಶ ಮಟ್ಟ ಅಥವಾ ಭದ್ರತಾ ಮಟ್ಟವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆಯೇ ಎಂಬುದರ ಹೊರತಾಗಿಯೂ, ಬಹು ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರಕಾರಗಳಿಗಾಗಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಡೊಮೇನ್ ಹೆಸರನ್ನು ಬಳಸುವ ಮೊದಲು ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದಿರಿ. ಮರುನಿರ್ದೇಶನ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಒಂದು ಗೋಚರ ವೆಬ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಬಹು ವೆಬ್ ಸರ್ವರ್‌ಗಳನ್ನು ಮರೆಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿಡಿ.

ಓಹ್, ಮತ್ತು ನಿಮ್ಮ ಡೊಮೇನ್ ಹೆಸರಿನ ಬಗ್ಗೆ ಯೋಚಿಸಿ. ನೀವು ಉತ್ಪನ್ನದ ಸಾಲುಗಳನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಮತ್ತು ಸೋಪ್ ತಯಾರಿಕೆಯನ್ನು ನಿಲ್ಲಿಸಿದ ನಂತರ ನೀವು soap.com ಎಂದು ಉಲ್ಲೇಖಿಸಲು ಬಯಸುವುದಿಲ್ಲ (ಸದ್ಯಕ್ಕೆ soap.com ಅನ್ನು ಹೊಂದಿರುವವರಿಗೆ ಕ್ಷಮಿಸಿ).

ತೀರ್ಮಾನಕ್ಕೆ

URI ಅನ್ನು 2, 20, 200, ಅಥವಾ 2000 ವರ್ಷಗಳವರೆಗೆ ಸಂರಕ್ಷಿಸುವುದು ನಿಸ್ಸಂಶಯವಾಗಿ ತೋರುವಷ್ಟು ಸುಲಭವಲ್ಲ. ಆದಾಗ್ಯೂ, ಅಂತರ್ಜಾಲದಾದ್ಯಂತ, ವೆಬ್‌ಮಾಸ್ಟರ್‌ಗಳು ಭವಿಷ್ಯದಲ್ಲಿ ಈ ಕಾರ್ಯವನ್ನು ನಿಜವಾಗಿಯೂ ಕಷ್ಟಕರವಾಗಿಸುವ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದಾರೆ. ಆಗಾಗ್ಗೆ ಇದು ಏಕೆಂದರೆ ಅವರು ಈ ಸಮಯದಲ್ಲಿ ಉತ್ತಮ ಸೈಟ್ ಅನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತಾರೆ - ಮತ್ತು ಎಲ್ಲವೂ ಬದಲಾದಾಗ ಲಿಂಕ್‌ಗಳಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಯಾರೂ ನಿರ್ಣಯಿಸಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಇಲ್ಲಿರುವ ಅಂಶವೆಂದರೆ ಹಲವು, ಹಲವು ವಿಷಯಗಳು ಬದಲಾಗಬಹುದು ಮತ್ತು ನಿಮ್ಮ URI ಗಳು ಹಾಗೆಯೇ ಉಳಿಯಬಹುದು. ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ರಚಿಸುತ್ತೀರಿ ಎಂದು ಯೋಚಿಸಿದಾಗ ಮಾತ್ರ ಇದು ಸಾಧ್ಯ.

ಇದನ್ನೂ ನೋಡಿ:

ಇದೇ ವಿಷಯದ ಬಗ್ಗೆ ಜಾಕೋಬ್ ನೀಲ್ಸನ್ ಅವರ ಟೀಕೆ

ಸೇರ್ಪಡಿಕೆಗಳು

ಫೈಲ್ ವಿಸ್ತರಣೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಹೇಗೆ...

...ಪ್ರಸ್ತುತ ಫೈಲ್-ಆಧಾರಿತ ವೆಬ್ ಸರ್ವರ್‌ನಲ್ಲಿರುವ URI ನಿಂದ?

ನೀವು Apache ಅನ್ನು ಬಳಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ವಿಷಯವನ್ನು ಮಾತುಕತೆ ಮಾಡಲು ನೀವು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಫೈಲ್ ವಿಸ್ತರಣೆಯನ್ನು (ಉದಾ. .png) ಫೈಲ್‌ಗೆ ಉಳಿಸಿ (ಉದಾ. mydog.png), ಆದರೆ ನೀವು ಇಲ್ಲದೆಯೇ ವೆಬ್ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಬಹುದು. ಅಪಾಚೆ ಆ ಹೆಸರು ಮತ್ತು ಯಾವುದೇ ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳಿಗಾಗಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಸೆಟ್‌ನಿಂದ ಉತ್ತಮವಾದದನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, GIF ಮತ್ತು PNG). ಮತ್ತು ವಿವಿಧ ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ ವಿವಿಧ ರೀತಿಯ ಫೈಲ್‌ಗಳನ್ನು ಹಾಕುವ ಅಗತ್ಯವಿಲ್ಲ, ವಾಸ್ತವವಾಗಿ ನೀವು ಹಾಗೆ ಮಾಡಿದರೆ ವಿಷಯ ಹೊಂದಾಣಿಕೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ವಿಷಯವನ್ನು ಮಾತುಕತೆ ಮಾಡಲು ನಿಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಿ
ವಿಸ್ತರಣೆಯಿಲ್ಲದೆ ಯಾವಾಗಲೂ URI ಗಳಿಗೆ ಲಿಂಕ್ ಮಾಡಿ

ವಿಸ್ತರಣೆಗಳೊಂದಿಗಿನ ಲಿಂಕ್‌ಗಳು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಪ್ರಸ್ತುತ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಉತ್ತಮ ಸ್ವರೂಪವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ನಿಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ.

(ವಾಸ್ತವವಾಗಿ, mydog, mydog.png и mydog.gif - ಮಾನ್ಯ ವೆಬ್ ಸಂಪನ್ಮೂಲಗಳು, mydog ಒಂದು ಸಾರ್ವತ್ರಿಕ ವಿಷಯ ಪ್ರಕಾರದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ, ಮತ್ತು mydog.png и mydog.gif - ನಿರ್ದಿಷ್ಟ ವಿಷಯ ಪ್ರಕಾರದ ಸಂಪನ್ಮೂಲಗಳು).

ಸಹಜವಾಗಿ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಬರೆಯುತ್ತಿದ್ದರೆ, ಅನಿಯಮಿತ ಡೇಟಾಬೇಸ್ ಬೆಳವಣಿಗೆಯ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿದ್ದರೂ, ನಿರಂತರ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಅವುಗಳ ಪ್ರಸ್ತುತ ರೂಪಕ್ಕೆ ಬಂಧಿಸಲು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುವುದು ಒಳ್ಳೆಯದು.

ಬೋರ್ಡ್ ಆಫ್ ಶೇಮ್ - ಕಥೆ 1: ಚಾನೆಲ್ 7

1999 ರ ಸಮಯದಲ್ಲಿ, ನಾನು ಪುಟದಲ್ಲಿ ಹಿಮದ ಕಾರಣದಿಂದಾಗಿ ಶಾಲೆ ಮುಚ್ಚುವಿಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ್ದೇನೆ http://www.whdh.com/stormforce/closings.shtml. ಟಿವಿ ಪರದೆಯ ಕೆಳಭಾಗದಲ್ಲಿ ಮಾಹಿತಿ ಕಾಣಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಕಾಯಬೇಡಿ! ನನ್ನ ಮುಖಪುಟದಿಂದ ನಾನು ಅದಕ್ಕೆ ಲಿಂಕ್ ಮಾಡಿದ್ದೇನೆ. 2000 ರ ಮೊದಲ ದೊಡ್ಡ ಹಿಮ ಚಂಡಮಾರುತವು ಆಗಮಿಸುತ್ತದೆ ಮತ್ತು ನಾನು ಪುಟವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ. ಅಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ:,

- ಇದರ ಪ್ರಕಾರ.
ಪ್ರಸ್ತುತ ಯಾವುದನ್ನೂ ಮುಚ್ಚಿಲ್ಲ. ಹವಾಮಾನ ಎಚ್ಚರಿಕೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ದಯವಿಟ್ಟು ಹಿಂತಿರುಗಿ.

ಇದು ಅಂತಹ ಬಲವಾದ ಚಂಡಮಾರುತವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ. ದಿನಾಂಕ ಕಾಣೆಯಾಗಿರುವುದು ತಮಾಷೆಯಾಗಿದೆ. ಆದರೆ ನೀವು ಸೈಟ್‌ನ ಮುಖ್ಯ ಪುಟಕ್ಕೆ ಹೋದರೆ, "ಮುಚ್ಚಿದ ಶಾಲೆಗಳು" ಎಂಬ ದೊಡ್ಡ ಬಟನ್ ಇರುತ್ತದೆ, ಅದು ಪುಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ http://www.whdh.com/stormforce/ ಮುಚ್ಚಿದ ಶಾಲೆಗಳ ದೀರ್ಘ ಪಟ್ಟಿಯೊಂದಿಗೆ.

ಬಹುಶಃ ಅವರು ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಾಯಿಸಿರಬಹುದು - ಆದರೆ ಅವರು URI ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಬೋರ್ಡ್ ಆಫ್ ಶೇಮ್ - ಕಥೆ 2: ಮೈಕ್ರೋಸಾಫ್ಟ್ ನೆಟ್‌ಮೀಟಿಂಗ್

ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚುತ್ತಿರುವ ಅವಲಂಬನೆಯೊಂದಿಗೆ, ತಯಾರಕರ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಲಿಂಕ್‌ಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಬಹುದು ಎಂಬ ಬುದ್ಧಿವಂತ ಕಲ್ಪನೆ ಬಂದಿತು. ಇದನ್ನು ಸಾಕಷ್ಟು ಬಳಸಲಾಗಿದೆ ಮತ್ತು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಲಾಗಿದೆ, ಆದರೆ ನೀವು URL ಅನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇನ್ನೊಂದು ದಿನ ನಾನು ವೆಬ್/ಫ್ರೀ ಸ್ಟಫ್ ಮೆನುವಿನಲ್ಲಿ ಸಹಾಯ/ಮೈಕ್ರೋಸಾಫ್ಟ್‌ನಲ್ಲಿ Microsoft Netmeeting 2/ಏನೋ ಕ್ಲೈಂಟ್‌ನಿಂದ ಲಿಂಕ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು 404 ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿದೆ - ಸರ್ವರ್‌ನಿಂದ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಕಂಡುಬಂದಿಲ್ಲ. ಬಹುಶಃ ಅದನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ ...

ಐತಿಹಾಸಿಕ ಟಿಪ್ಪಣಿ: 20 ನೇ ಶತಮಾನದ ಕೊನೆಯಲ್ಲಿ, ಇದನ್ನು ಬರೆಯಲ್ಪಟ್ಟಾಗ, "ಕೂಲ್" ಎಂಬುದು ಅನುಮೋದನೆಯ ವಿಶೇಷಣವಾಗಿತ್ತು, ವಿಶೇಷವಾಗಿ ಯುವ ಜನರಲ್ಲಿ, ಫ್ಯಾಶನ್, ಗುಣಮಟ್ಟ ಅಥವಾ ಸೂಕ್ತತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಆತುರದಲ್ಲಿ, URI ಮಾರ್ಗವನ್ನು ಉಪಯುಕ್ತತೆ ಅಥವಾ ಬಾಳಿಕೆಗಿಂತ ಹೆಚ್ಚಾಗಿ "ತಂಪು" ಗಾಗಿ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ಈ ಪೋಸ್ಟ್ ತಂಪಾದ ಹುಡುಕಾಟದ ಹಿಂದಿನ ಶಕ್ತಿಯನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ ಪ್ರಯತ್ನವಾಗಿದೆ.

ಮೂಲ: www.habr.com