ผู้แต่ง: เซอร์ ทิม เบอร์เนอร์ส-ลี ผู้ประดิษฐ์ 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
ที่นี่ส่วนหัว pubs/1998 จะให้เบาะแสที่ดีแก่บริการเก็บถาวรในอนาคตว่าแผนการจำแนกประเภทเอกสารเก่าปี 1998 มีผลบังคับใช้ แม้ว่าหมายเลขเอกสารอาจดูแตกต่างออกไปในปี 2098 แต่ฉันจินตนาการว่า URI นี้จะยังคงใช้ได้และจะไม่รบกวน NSF หรือองค์กรอื่นใดที่จะดูแลไฟล์เก็บถาวร
ฉันไม่คิดว่า URL จะต้องคงอยู่ถาวร - มี URN อยู่
นี่อาจเป็นหนึ่งในผลข้างเคียงที่เลวร้ายที่สุดของการอภิปราย URN บางคนคิดว่าเนื่องจากการค้นคว้าเกี่ยวกับเนมสเปซที่ถาวรมากขึ้น พวกเขาอาจไม่ใส่ใจกับลิงก์ที่ห้อยต่องแต่ง เพราะ "URN จะแก้ไขปัญหาทั้งหมดนั้น" หากคุณเป็นหนึ่งในคนเหล่านี้ ฉันขอทำให้คุณผิดหวัง
รูปแบบ URN ส่วนใหญ่ที่ฉันเคยเห็นมีลักษณะเหมือนตัวระบุสิทธิ์ ตามด้วยวันที่และสตริงที่คุณเลือก หรือเพียงสตริงที่คุณเลือก สิ่งนี้คล้ายกับ HTTP URI มาก กล่าวอีกนัยหนึ่ง หากคุณคิดว่าองค์กรของคุณจะสามารถสร้าง URN ที่มีอายุการใช้งานยาวนานได้ ให้พิสูจน์ทันทีโดยใช้สิ่งเหล่านั้นสำหรับ HTTP URI ของคุณ ไม่มีสิ่งใดใน HTTP ที่ทำให้ URI ของคุณไม่เสถียร เฉพาะองค์กรของคุณเท่านั้น สร้างฐานข้อมูลที่แมปเอกสาร URN กับชื่อไฟล์ปัจจุบัน และปล่อยให้เว็บเซิร์ฟเวอร์ใช้เพื่อเรียกค้นไฟล์จริงๆ
หากคุณมาถึงจุดนี้แล้ว หากคุณไม่มีเวลา เงิน และการเชื่อมต่อในการพัฒนาซอฟต์แวร์บางอย่าง คุณสามารถระบุข้อแก้ตัวต่อไปนี้ได้:
เราต้องการทำเช่นนั้น แต่เราเพียงแต่ไม่มีเครื่องมือที่เหมาะสม
แต่คุณสามารถเห็นใจกับสิ่งนี้ ฉันเห็นด้วยอย่างยิ่ง สิ่งที่คุณต้องทำคือบังคับให้เว็บเซิร์ฟเวอร์แยกวิเคราะห์ URI ถาวรทันทีและส่งคืนไฟล์ทุกที่ที่จัดเก็บไว้ในระบบไฟล์บ้าปัจจุบันของคุณ คุณต้องการจัดเก็บ URI ทั้งหมดในไฟล์เป็นเช็คและรักษาฐานข้อมูลให้ทันสมัยอยู่เสมอ คุณต้องการรักษาความสัมพันธ์ระหว่างเวอร์ชันต่างๆ และการแปลของเอกสารเดียวกัน และยังรักษาบันทึกการตรวจสอบอิสระเพื่อให้แน่ใจว่าไฟล์จะไม่เสียหายจากข้อผิดพลาดโดยไม่ตั้งใจ และเว็บเซิร์ฟเวอร์ก็ไม่ได้มาพร้อมกับคุณสมบัติเหล่านี้ทันที เมื่อคุณต้องการสร้างเอกสารใหม่ โปรแกรมแก้ไขจะขอให้คุณระบุ URI
คุณต้องสามารถเปลี่ยนความเป็นเจ้าของ การเข้าถึงเอกสาร การรักษาความปลอดภัยระดับการเก็บถาวร ฯลฯ ในพื้นที่ URI โดยไม่ต้องเปลี่ยน URI
มันเลวร้ายเกินไป แต่เราจะแก้ไขสถานการณ์ ที่ W3C เราใช้ฟังก์ชัน Jigedit (เซิร์ฟเวอร์แก้ไขจิ๊กซอว์) ที่ติดตามเวอร์ชัน และเราทดลองกับสคริปต์การสร้างเอกสาร หากคุณพัฒนาเครื่องมือ เซิร์ฟเวอร์ และไคลเอนต์ โปรดใส่ใจกับปัญหานี้!
ข้อแก้ตัวนี้ยังใช้ได้กับเพจ W3C หลายหน้า รวมถึงเพจนี้ด้วย ดังนั้นจงทำตามที่ฉันพูด ไม่ใช่อย่างที่ฉันทำ
ทำไมฉันต้องสนใจ?
เมื่อคุณเปลี่ยน URI บนเซิร์ฟเวอร์ คุณจะไม่มีทางบอกได้เลยว่าใครจะมีลิงก์ไปยัง URI เก่า สิ่งเหล่านี้อาจเป็นลิงก์จากหน้าเว็บปกติ บุ๊คมาร์คหน้าของคุณ URI อาจถูกเขียนลวกๆ ไว้ตรงขอบของจดหมายถึงเพื่อน
เมื่อมีคนติดตามลิงก์แล้วลิงก์เสียหาย พวกเขามักจะสูญเสียความไว้วางใจในเจ้าของเซิร์ฟเวอร์ เขายังหงุดหงิดทั้งทางอารมณ์และทางร่างกายที่ไม่สามารถบรรลุเป้าหมายได้
มีคนจำนวนมากบ่นเกี่ยวกับลิงก์ที่เสียอยู่ตลอดเวลา และฉันหวังว่าความเสียหายจะหายไปอย่างชัดเจน ฉันหวังว่าความเสียหายต่อชื่อเสียงต่อผู้ดูแลเซิร์ฟเวอร์ที่เอกสารหายไปก็ชัดเจนเช่นกัน
แล้วฉันควรทำอย่างไร? การออกแบบยูริ
เป็นความรับผิดชอบของเว็บมาสเตอร์ในการจัดสรร URI ที่สามารถใช้งานได้ใน 2 ปี, ใน 20 ปี, ใน 200 ปี สิ่งนี้ต้องใช้ความรอบคอบ การจัดระบบ และความมุ่งมั่น
URI เปลี่ยนแปลงหากข้อมูลใดๆ ในนั้นเปลี่ยนแปลง วิธีที่คุณออกแบบมันเป็นสิ่งสำคัญมาก (อะไรนะ การออกแบบ URI ฉันจำเป็นต้องออกแบบ URI หรือไม่ ใช่ คุณควรคิดถึงเรื่องนั้น) โดยพื้นฐานแล้วการออกแบบหมายถึงการละทิ้งข้อมูลใดๆ ใน URI
วันที่สร้างเอกสาร - วันที่ออก URI - เป็นสิ่งที่จะไม่มีวันเปลี่ยนแปลง มีประโยชน์มากสำหรับการแยกแบบสอบถามที่ใช้ระบบใหม่ออกจากแบบสอบถามที่ใช้ระบบเก่า นี่เป็นจุดเริ่มต้นที่ดีในการเริ่มต้นด้วย URI หากเอกสารเป็นวันที่ แม้ว่าเอกสารจะมีความเกี่ยวข้องในอนาคต นี่ก็ถือเป็นการเริ่มต้นที่ดี
ข้อยกเว้นเพียงอย่างเดียวคือเพจที่ตั้งใจให้เป็นเวอร์ชัน "ล่าสุด" เช่น สำหรับทั้งองค์กรหรือส่วนใหญ่
http://www.pathfinder.com/money/moneydaily/latest/
นี่คือคอลัมน์ Money Daily ล่าสุดในนิตยสาร Money เหตุผลหลักที่ไม่จำเป็นต้องมีวันที่ใน URI นี้คือไม่มีเหตุผลที่จะจัดเก็บ URI ที่จะคงอยู่ได้นานกว่าบันทึก แนวคิดของ Money Daily จะหายไปเมื่อ Money หายไป หากคุณต้องการลิงก์ไปยังเนื้อหา คุณควรลิงก์ไปยังเนื้อหานั้นแยกกันในเอกสารสำคัญ:
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(ดูดี สันนิษฐานว่า "เงิน" จะหมายถึงสิ่งเดียวกันตลอดชีวิตของ pathfinder.com มี "98" ที่ซ้ำกันและ ".html" ที่ไม่จำเป็น แต่อย่างอื่นดูเหมือน URI ที่แข็งแกร่ง
อะไรจะทิ้งไป.
ทั้งหมด! นอกเหนือจากวันที่สร้าง การใส่ข้อมูลใดๆ ใน URI เป็นการถามถึงปัญหาไม่ทางใดก็ทางหนึ่ง
- ชื่อผู้แต่ง. การประพันธ์อาจมีการเปลี่ยนแปลงเมื่อมีเวอร์ชันใหม่ให้ใช้งาน ผู้คนออกจากองค์กรและส่งต่อให้กับผู้อื่น
- สิ่ง. มันยากมาก. ในตอนแรกมันดูดีอยู่เสมอ แต่การเปลี่ยนแปลงอย่างรวดเร็วอย่างน่าประหลาดใจ ฉันจะพูดเพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง
- สถานะ. ไดเร็กทอรีเช่น "เก่า", "ร่าง" และอื่นๆ ไม่ต้องพูดถึง "ล่าสุด" และ "เจ๋ง" จะปรากฏในทุกระบบไฟล์ เอกสารเปลี่ยนสถานะ - ไม่เช่นนั้นการสร้างร่างจะไม่มีประโยชน์ เอกสารเวอร์ชันล่าสุดต้องมีตัวระบุถาวร โดยไม่คำนึงถึงสถานะ ให้สถานะไม่อยู่ในชื่อ
- เข้าไป. ที่ W3C เราได้แบ่งไซต์ออกเป็นส่วนต่างๆ สำหรับพนักงาน สมาชิก และบุคคลทั่วไป ฟังดูดี แต่แน่นอนว่าเอกสารเริ่มต้นจากแนวคิดของทีมจากเจ้าหน้าที่ มีการหารือกับสมาชิก และจากนั้นจึงกลายเป็นความรู้สาธารณะ คงจะน่าเสียดายจริงๆ ถ้าทุกครั้งที่เปิดเอกสารเพื่อการอภิปรายในวงกว้าง ลิงก์เก่าๆ ที่เชื่อมโยงไปถึงเอกสารนั้นก็จะใช้งานไม่ได้! ตอนนี้เรามาดูรหัสวันที่แบบง่ายๆ
- นามสกุลไฟล์. ปรากฏการณ์ที่พบบ่อยมาก "cgi" แม้แต่ ".html" ก็จะมีการเปลี่ยนแปลงในอนาคต คุณอาจไม่ได้ใช้ HTML สำหรับหน้านี้มา 20 ปีแล้ว แต่ลิงก์ไปยังหน้านี้ในปัจจุบันควรจะยังใช้งานได้ ลิงก์ Canonical บนไซต์ W3C ไม่ได้ใช้ส่วนขยาย ().
- กลไกซอฟต์แวร์. ใน URI ให้มองหา "cgi", "exec" และคำอื่นๆ ที่ระบุว่า "ดูซอฟต์แวร์ที่เราใช้อยู่" มีใครอยากใช้เวลาทั้งชีวิตในการเขียนสคริปต์ Perl CGI บ้างไหม? เลขที่? จากนั้นลบนามสกุล .pl ออก อ่านคู่มือเซิร์ฟเวอร์เกี่ยวกับวิธีการทำเช่นนี้
- ชื่อดิสก์ มาเร็ว! แต่ฉันเคยเห็นสิ่งนี้
ตัวอย่างที่ดีที่สุดจากเว็บไซต์ของเราก็คือ
http://www.w3.org/1998/12/01/chairs
... รายงานรายงานการประชุมประธาน W3C
หัวข้อและการจำแนกตามหัวข้อ
ฉันจะลงรายละเอียดเพิ่มเติมเกี่ยวกับอันตรายนี้ เนื่องจากเป็นหนึ่งในสิ่งที่หลีกเลี่ยงได้ยากที่สุด โดยทั่วไปแล้ว หัวข้อจะจบลงใน URI เมื่อคุณจัดหมวดหมู่เอกสารตามงานที่ทำ แต่รายละเอียดนี้จะเปลี่ยนแปลงไปตามกาลเวลา ชื่อของพื้นที่จะเปลี่ยนไป ที่ W3C เราต้องการเปลี่ยน MarkUP เป็น Markup จากนั้นเป็น HTML เพื่อสะท้อนถึงเนื้อหาจริงของส่วนนั้น นอกจากนี้ มักจะมีเนมสเปซแบบเรียบๆ อีก 100 ปีข้างหน้า คุณแน่ใจหรือว่าคุณจะไม่ต้องการใช้สิ่งใดซ้ำอีก ในช่วงชีวิตอันแสนสั้นของเรา เราต้องการนำ "History" และ "Style Sheets" มาใช้ซ้ำแล้ว เป็นต้น
เป็นวิธีที่ดึงดูดใจในการจัดระเบียบเว็บไซต์ และเป็นวิธีที่ดึงดูดใจอย่างแท้จริงในการจัดระเบียบทุกอย่าง รวมถึงเว็บทั้งหมดด้วย นี่เป็นวิธีแก้ปัญหาระยะกลางที่ดี แต่ก็มีข้อบกพร่องร้ายแรงในระยะยาว
เหตุผลส่วนหนึ่งอยู่ที่ปรัชญาแห่งความหมาย ทุกคำในภาษาเป็นเป้าหมายที่เป็นไปได้สำหรับการรวมกลุ่ม และแต่ละคนอาจมีแนวคิดที่แตกต่างกันว่าหมายถึงอะไร เนื่องจากความสัมพันธ์ระหว่างเอนทิตีเป็นเหมือนเว็บมากกว่าต้นไม้ แม้แต่ผู้ที่เห็นด้วยกับเว็บก็อาจเลือกการนำเสนอต้นไม้ที่แตกต่างกันได้ นี่คือข้อสังเกตทั่วไปของฉัน (ซ้ำหลายครั้ง) เกี่ยวกับอันตรายของการจำแนกประเภทตามลำดับชั้นซึ่งเป็นวิธีแก้ปัญหาทั่วไป
ที่จริงแล้ว เมื่อคุณใช้ชื่อหัวข้อใน 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) แต่คุณสามารถลิงก์ไปยังทรัพยากรบนเว็บได้โดยไม่ต้องใช้ลิงก์ดังกล่าว จากนั้น Apache จะตรวจสอบไดเรกทอรีเพื่อหาไฟล์ทั้งหมดที่มีชื่อนั้นและนามสกุลใดๆ และสามารถเลือกไฟล์ที่ดีที่สุดจากชุดได้ (เช่น 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: Microsoft Netmeeting
เนื่องจากการพึ่งพาอินเทอร์เน็ตเพิ่มมากขึ้น จึงมีแนวคิดที่ชาญฉลาดว่าลิงก์ไปยังเว็บไซต์ของผู้ผลิตสามารถฝังอยู่ในแอปพลิเคชันได้ สิ่งนี้ถูกใช้และถูกละเมิดบ่อยครั้ง แต่คุณไม่สามารถเปลี่ยน URL ได้ เมื่อวันก่อนฉันลองใช้ลิงก์จาก Microsoft Netmeeting 2/ไคลเอ็นต์บางอย่างในเมนู Help/Microsoft บนเว็บ/ของฟรี และได้รับข้อผิดพลาด 404 - ไม่พบการตอบสนองจากเซิร์ฟเวอร์ บางทีมันอาจจะได้รับการแก้ไขแล้ว...
© 1998
หมายเหตุทางประวัติศาสตร์: ในช่วงปลายศตวรรษที่ 20 เมื่อมีการเขียนข้อความนี้ "ความเท่" เป็นสัญลักษณ์ของการยอมรับ โดยเฉพาะในหมู่คนหนุ่มสาว ซึ่งบ่งบอกถึงความทันสมัย คุณภาพ หรือความเหมาะสม ด้วยความเร่งรีบ เส้นทาง URI มักถูกเลือกเพราะ "ความเย็น" มากกว่าความมีประโยชน์หรือความทนทาน โพสต์นี้เป็นความพยายามที่จะเปลี่ยนเส้นทางพลังงานที่อยู่เบื้องหลังการค้นหาความเท่
ที่มา: will.com