ค่าสัมบูรณ์เทียบกับ URL สัมพัทธ์

ฉันต้องการทราบความแตกต่างระหว่าง URL ทั้งสองประเภทนี้: URL ที่เกี่ยวข้อง (สำหรับรูปภาพ, ไฟล์ CSS, ไฟล์ JS, ฯลฯ ) และ URL แบบสัมบูรณ์

นอกจากนี้จะใช้อันไหนดีกว่ากัน?

โดยทั่วไปถือว่าเป็นแนวปฏิบัติที่ดีที่สุดในการใช้ URL สัมพัทธ์เพื่อให้เว็บไซต์ของคุณจะไม่ถูกผูกไว้กับ URL ฐานที่มีการปรับใช้ในปัจจุบัน ตัวอย่างเช่นจะสามารถทำงานกับ localhost รวมถึงในโดเมนสาธารณะของคุณโดยไม่มีการดัดแปลง

ฉันควรใช้ URL แบบสัมบูรณ์หรือแบบสัมพัทธ์

หากคุณใช้ URL แบบสัมบูรณ์หมายความว่า URL รวมถึงแบบแผน (เช่น http / https) และชื่อโฮสต์ (เช่น yourdomain.com) จะไม่ทำเช่นนั้น (สำหรับแหล่งข้อมูลในพื้นที่) เพราะการบำรุงรักษาและการดีบักจะแย่มาก

สมมติว่าคุณได้ใช้ URL <img src="http://yourdomain.com/images/example.png">แบบเต็มทุกที่ในรหัสของคุณเช่น ตอนนี้จะเกิดอะไรขึ้นเมื่อคุณไปที่:

• เปลี่ยนเป็นรูปแบบอื่น (เช่น http -> https)
• สลับชื่อโดเมน (test.yourdomain.com -> yourdomain.com)

ในตัวอย่างแรกสิ่งที่จะเกิดขึ้นคือคุณจะได้รับคำเตือนเกี่ยวกับเนื้อหาที่ไม่ปลอดภัยซึ่งถูกร้องขอบนหน้าเว็บ เนื่องจาก URL ทั้งหมดของคุณถูกเข้ารหัสเพื่อใช้ http (: //yourdomain.com/images/example.png) และเมื่อเรียกใช้หน้าเว็บของคุณผ่าน https เบราว์เซอร์คาดว่าจะโหลดทรัพยากรทั้งหมดผ่าน https เพื่อป้องกันการรั่วไหลของข้อมูล

ในตัวอย่างที่สองเมื่อวางเว็บไซต์ของคุณแบบสดจากสภาพแวดล้อมการทดสอบหมายความว่าทรัพยากรทั้งหมดยังคงชี้ไปที่โดเมนทดสอบของคุณแทนที่จะเป็นโดเมนสด

ดังนั้นเพื่อตอบคำถามของคุณเกี่ยวกับว่าจะใช้ URL แบบสัมบูรณ์หรือแบบสัมพัทธ์: ใช้ URL แบบสัมพัทธ์เสมอ (สำหรับทรัพยากรในพื้นที่)

URL ต่างกันมีความแตกต่างกันอย่างไร

ก่อนอื่นมาดู URL ประเภทต่าง ๆ ที่เราสามารถใช้ได้:

• http://yourdomain.com/images/example.png
• //yourdomain.com/images/example.png
• /images/example.png
• images/example.png

URL เหล่านี้พยายามเข้าถึงทรัพยากรใดบนเซิร์ฟเวอร์

/var/www/mywebsiteในตัวอย่างด้านล่างผมถือว่าเว็บไซต์จะวิ่งออกมาจากสถานที่ดังต่อไปนี้บนเซิร์ฟเวอร์

http://yourdomain.com/images/example.png

ข้างต้น (แน่นอน) พยายาม URL /var/www/website/images/example.pngในการเข้าถึงทรัพยากร ประเภทของ URL นี้เป็นสิ่งที่คุณจะเสมอต้องการหลีกเลี่ยงการขอทรัพยากรจากเว็บไซต์ของคุณเองด้วยเหตุผลข้างต้น อย่างไรก็ตามมันมีสถานที่ ตัวอย่างเช่นหากคุณมีเว็บไซต์http://yourdomain.comและคุณต้องการขอทรัพยากรจากโดเมนภายนอกผ่าน https คุณควรใช้สิ่งนี้ https://externalsite.com/path/to/image.pngเช่น

//yourdomain.com/images/example.png

URL นี้สัมพันธ์โดยยึดตามรูปแบบปัจจุบันที่ใช้และควรใช้เกือบตลอดเวลาเมื่อรวมถึงแหล่งข้อมูลภายนอก (รูปภาพ, javascripts ฯลฯ )

URL ประเภทนี้ใช้รูปแบบปัจจุบันของหน้าเว็บที่เปิดอยู่ ซึ่งหมายความว่าคุณจะอยู่บนหน้าเว็บhttp://yourdomain.comและในหน้านั้นเป็นแท็กรูปภาพ<img src="//yourdomain.com/images/example.png">URL http://yourdomain.com/images/example.pngของภาพที่จะแก้ไขใน
เมื่อคุณจะได้รับบนหน้าเว็บhttp**s**://yourdomain.comและในหน้านั้นเป็นแท็กรูปภาพ<img src="//yourdomain.com/images/example.png">URL https://yourdomain.com/images/example.pngของภาพที่จะแก้ไขใน

นี้ป้องกันทรัพยากรโหลดผ่าน HTTPS เมื่อมันไม่ได้จำเป็นโดยอัตโนมัติและทำให้แน่ใจว่าทรัพยากรที่มีการร้องขอผ่าน HTTPS เมื่อมันเป็นสิ่งจำเป็น

URL ด้านบนจะแก้ไขในลักษณะเดียวกับฝั่งเซิร์ฟเวอร์เป็น URL ก่อนหน้า:

ข้างต้น (แน่นอน) พยายาม URL /var/www/website/images/example.pngในการเข้าถึงทรัพยากร

/images/example.png

สำหรับทรัพยากรในท้องถิ่นนี่เป็นวิธีการอ้างอิงที่ต้องการ นี่คือ URL สัมพัทธ์ตามรากของเอกสาร ( /var/www/mywebsite) ของเว็บไซต์ของคุณ ซึ่งหมายความว่าเมื่อคุณมี<img src="/images/example.png">มันจะเสมอ/var/www/mywebsite/images/example.pngมติ

หากถึงจุดหนึ่งคุณตัดสินใจที่จะเปลี่ยนโดเมนมันจะยังคงทำงานเพราะมันเป็นญาติ

images/example.png

นี่เป็น URL ที่เกี่ยวข้องแม้ว่าจะแตกต่างจาก URL ก่อนหน้าเล็กน้อย URL นี้สัมพันธ์กับเส้นทางปัจจุบัน สิ่งนี้หมายความว่ามันจะแก้ไขเส้นทางที่แตกต่างกันขึ้นอยู่กับว่าคุณอยู่ในเว็บไซต์

ตัวอย่างเช่นเมื่อคุณอยู่บนหน้าเว็บhttp://yourdomain.comและคุณใช้<img src="images/example.png">มันจะแก้ปัญหาบนเซิร์ฟเวอร์เพื่อ/var/www/mywebsite/images/example.pngเป็นไปตามคาด แต่เมื่อคุณอยู่บนหน้าและคุณใช้แท็กรูปภาพเดียวกันแน่นอนมันก็จะแก้ไปhttp://yourdomain.com/some/path/var/www/mywebsite/some/path/images/example.png

ควรใช้เมื่อใด

เมื่อร้องขอทรัพยากรภายนอกคุณมักจะต้องการใช้ URL ที่สัมพันธ์กับแบบแผน (ยกเว้นว่าคุณต้องการบังคับให้มีแบบแผนอื่น) และเมื่อจัดการกับทรัพยากรในท้องถิ่นที่คุณต้องการใช้ URL แบบสัมพันธ์โดยอ้างอิงจากรูทเอกสาร

เอกสารตัวอย่าง:

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
        <link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
    </head>
    <body>
        <img src="/images/some/localimage.png" alt="">
        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
    </body>
</html>

บางส่วน (kinda) ซ้ำกัน

• วิธีที่ปลอดภัยในการเขียน URL ที่ถ่ายโอนข้ามสภาพแวดล้อม
• วิธีที่ถูกต้องในการเชื่อมโยงภาพในเว็บไซต์คืออะไร?

ดูสิ่งนี้: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ /   \________________/\_________/ \__/            \___/ \_/ \_________/ \_________/ \__/
 |           |               |       |                |    |       |           |       |
 |       userinfo         hostname  port              |    |       parameter query  fragment
 |    \_______________________________/ \_____________|____|____________/
scheme                  |                               | |  |
 |                authority                           |path|
 |                                                    |    |
 |            path                       interpretable as filename
 |   ___________|____________                              |
/ \ /                        \                             |
urn:example:animal:ferret:nose               interpretable as extension

URL ที่แน่นอนรวมถึงส่วนต่าง ๆ ก่อนส่วน "เส้นทาง" - กล่าวอีกนัยหนึ่งมันรวมถึงแบบแผน ( httpในhttp://foo/bar/baz) และชื่อโฮสต์ ( fooในhttp://foo/bar/baz) (และพอร์ตเสริม userinfo และพอร์ต)

URL สัมพัทธ์เริ่มต้นด้วยเส้นทาง

URL ที่แน่นอนคือดีแน่นอน: ตำแหน่งของทรัพยากรสามารถแก้ไขได้โดยดูที่ URL เท่านั้น URL สัมพัทธ์มีความรู้สึกไม่สมบูรณ์: ในการแก้ไขคุณต้องมีแบบแผนและชื่อโฮสต์และโดยทั่วไปจะนำมาจากบริบทปัจจุบัน ตัวอย่างเช่นในหน้าเว็บที่

http://myhost/mypath/myresource1.html

คุณสามารถใส่ลิงค์ได้

<a href="pages/page1">click me</a>

ในแอhrefททริบิวของลิงค์นั้นจะใช้ url ที่สัมพันธ์กันและหากมีการคลิกมันจะต้องได้รับการแก้ไขเพื่อที่จะติดตามมัน ในกรณีนี้บริบทปัจจุบันคือ

http://myhost/mypath/myresource1.html

ดังนั้นสคีมาชื่อโฮสต์และเส้นทางชั้นนำของเหล่านี้จะถูกนำมาใช้ได้กับpages/page1ผลผลิต

http://myhost/mypath/pages/page1

หากลิงก์จะเป็นดังนี้:

<a href="/pages/page1">click me</a>

(โปรดสังเกตสิ่งที่/ปรากฏในตอนเริ่มต้นของ URL) จากนั้นจะได้รับการแก้ไขเป็น

http://myhost/pages/page1

เพราะผู้นำก็/แสดงถึงรูทของโฮสต์

ในการสมัครทางเว็บฉันจะแนะนำให้ใช้ URL สัมพัทธ์สำหรับแหล่งข้อมูลทั้งหมดที่เป็นของแอพของคุณ ด้วยวิธีนี้หากคุณเปลี่ยนตำแหน่งของหน้าเว็บทุกอย่างจะยังคงทำงานต่อไป แหล่งข้อมูลภายนอกใด ๆ (อาจเป็นหน้านอกแอปพลิเคชันของคุณ แต่ยังรวมถึงเนื้อหาแบบสแตติกที่คุณส่งผ่านเครือข่ายการจัดส่งเนื้อหา) ควรชี้ไปที่การใช้ URL แบบสัมบูรณ์: หากคุณไม่มีวิธีการค้นหาแบบง่าย ๆ อยู่บนเซิร์ฟเวอร์อื่น

สมมติว่าเรากำลังสร้างไซต์ย่อยที่มีไฟล์ที่อยู่ในโฟลเดอร์http://site.ru/shop

1. URL ที่แน่นอน

Link to home page
href="http://sites.ru/shop/"

Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"

2. URL สัมพัทธ์

Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"

Link from product page to home page
href="../../"

แม้ว่า URL สัมพัทธ์จะดูสั้นกว่าแบบสัมบูรณ์ แต่ URL แบบสัมบูรณ์จะดีกว่าเนื่องจากลิงก์สามารถใช้ไม่เปลี่ยนแปลงในหน้าใด ๆ ของไซต์

กรณีระดับกลาง

เราได้พิจารณาสองกรณีที่สำคัญ: URL ที่ "สมบูรณ์" และ "แน่นอน" แต่ทุกสิ่งมีความสัมพันธ์ในโลกนี้ สิ่งนี้ใช้กับ URL ด้วย ทุกครั้งที่คุณพูดเกี่ยวกับ URL ที่แน่นอนคุณควรระบุสัมพันธ์กับสิ่งที่

3. URL ที่สัมพันธ์กับโปรโตคอล

Link to home page
href="//sites.ru/shop/"

Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"

Google แนะนำ URL ดังกล่าว อย่างไรก็ตามในตอนนี้ก็ถือว่าโดยทั่วไปแล้วว่า http: // และ https: // เป็นเว็บไซต์ที่ต่างกัน

4. URL ที่สัมพันธ์กับรูท

คือเกี่ยวข้องกับโฟลเดอร์รูทของโดเมน

Link to home page
href="/shop/"

Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"

เป็นตัวเลือกที่ดีถ้าทุกหน้าอยู่ในโดเมนเดียวกัน เมื่อคุณย้ายเว็บไซต์ของคุณไปยังโดเมนอื่นคุณไม่จำเป็นต้องเปลี่ยนชื่อโดเมนใน URL เป็นจำนวนมาก

5. URL ที่สัมพันธ์กัน (สัมพันธ์กับโฮมเพจ)

แท็ก <base> ระบุ URL ฐานซึ่งจะถูกเพิ่มลงในลิงก์และจุดยึดทั้งหมดโดยอัตโนมัติ แท็กฐานไม่มีผลต่อลิงก์แบบสัมบูรณ์ ในฐานะ URL พื้นฐานเราจะระบุหน้าแรก: <base href = "http://sites.ru/shop/">

Link to home page
href=""

Link to product page
href="t-shirts/t-shirt-life-is-good/"

ตอนนี้คุณสามารถย้ายเว็บไซต์ของคุณไม่เพียง แต่โดเมนใด ๆ แต่ในโฟลเดอร์ย่อยใด ๆ เพียงจำไว้ว่าแม้ว่า URL จะดูเหมือนเป็นญาติ แต่ในความเป็นจริงแล้วพวกเขาจะสมบูรณ์ โดยเฉพาะอย่างยิ่งให้ความสนใจกับจุดยึด เพื่อนำทางภายในหน้าปัจจุบันเราต้องเขียน href = "t-shirts / t-shirt-life-is-good / # comments" not href = "# comments" หลังจะโยนในหน้าแรก

ข้อสรุป

สำหรับลิงก์ภายในฉันใช้ URL ที่เกี่ยวข้อง (5) สำหรับลิงก์ภายนอกและจดหมายข่าวฉันใช้ URL ที่แน่นอน (1)

มีสามประเภทจริง ๆ ที่ควรกล่าวถึงอย่างชัดเจน ในทางปฏิบัติแม้ว่า URL นั้นจะได้รับการจัดการให้อยู่ในระดับที่ต่ำกว่าและฉันจะบอกได้ว่านักพัฒนาสามารถใช้งานได้โดยไม่ต้องเขียน URL เพียงครั้งเดียวด้วยมือ

แน่นอน

URL ที่แน่นอนผูกรหัสของคุณกับโปรโตคอลและโดเมน สิ่งนี้สามารถเอาชนะได้ด้วย URL แบบไดนามิก

<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>

ข้อดีแน่นอน:

1. การควบคุม - สามารถควบคุมโดเมนย่อยและโปรโตคอลได้ ผู้ที่เข้าสู่โดเมนย่อยที่ไม่ชัดเจนจะถูกส่งเข้าช่องทางในโดเมนย่อยที่เหมาะสม คุณสามารถกระโดดไปมาระหว่างที่ปลอดภัยและไม่ปลอดภัยตามความเหมาะสม

2. กำหนดค่าได้ - นักพัฒนารักสิ่งต่าง ๆ อย่างแน่นอน คุณสามารถออกแบบอัลกอริทึมเรียบร้อยเมื่อใช้ URL ที่แน่นอน สามารถกำหนดค่า URL ได้เพื่อให้สามารถอัปเดต URL ทั่วทั้งไซต์โดยมีการเปลี่ยนแปลงครั้งเดียวในไฟล์กำหนดค่าเดียว

3. ทิพย์ - คุณสามารถค้นหาคนที่ขูดไซต์ของคุณหรืออาจรับลิงค์ภายนอกเพิ่มเติม

รูตสัมพัทธ์

URL สัมพัทธ์รูตจะผูกโค้ดของคุณกับ URL พื้นฐาน นี้สามารถเอาชนะด้วย URL แบบไดนามิกและ / หรือแท็กฐาน

<a href=“/index.php?q=”>.example.com/index.php?q=</a>

ข้อดีของรูตสัมพัทธ์:

1. กำหนดค่าได้ - แท็กฐานทำให้พวกเขาสัมพันธ์กับรูทใด ๆ ที่คุณเลือกทำให้การสลับโดเมนและการใช้เทมเพลตเป็นเรื่องง่าย

ญาติ

URL สัมพัทธ์ผูกรหัสของคุณกับโครงสร้างไดเรกทอรี ไม่มีทางที่จะเอาชนะสิ่งนี้ได้ URL สัมพัทธ์มีประโยชน์เฉพาะในระบบไฟล์สำหรับการสำรวจไดเรกทอรีหรือเป็นทางลัดสำหรับงานที่ต้องเลื่อนขั้น

<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />

ข้อเสียญาติ:

1. สับสน - วิธีการหลายจุดคือ? มีกี่โฟลเดอร์ ไฟล์อยู่ที่ไหน ทำไมมันไม่ทำงาน

2. การบำรุงรักษา - หากไฟล์ถูกย้ายโดยไม่ตั้งใจทรัพยากรออกจากการโหลดลิงค์ส่งผู้ใช้ไปยังหน้าผิดข้อมูลแบบฟอร์มอาจถูกส่งไปยังหน้าไม่ถูกต้อง หากจำเป็นต้องย้ายไฟล์ทรัพยากรทั้งหมดที่จะออกจากการโหลดและลิงก์ทั้งหมดที่จะไม่ถูกต้องจำเป็นต้องได้รับการอัปเดต

3. ไม่ได้ขนาด - เมื่อหน้าเว็บมีความซับซ้อนมากขึ้นและมุมมองเริ่มนำมาใช้ซ้ำในหลาย ๆ หน้าลิงก์ที่เกี่ยวข้องจะสัมพันธ์กับไฟล์ที่รวมอยู่ในนั้น หากคุณมีตัวอย่างข้อมูลการนำทางของ HTML ที่จะอยู่ในทุกหน้าความสัมพันธ์จะสัมพันธ์กับสถานที่ต่าง ๆ มากมาย สิ่งแรกที่ผู้คนรู้เมื่อพวกเขาเริ่มสร้างเทมเพลตคือพวกเขาต้องการวิธีจัดการ URL

4. คำนวณ - เบราว์เซอร์ของคุณใช้งานได้ (หวังว่าจะเป็นไปตาม RFC) ดูบทที่ 5 ในRFC3986

5. OOPS! - ข้อผิดพลาดหรือการพิมพ์ผิดอาจส่งผลให้กับดักแมงมุม

วิวัฒนาการของเส้นทาง

นักพัฒนาได้หยุดเขียน URL ในแง่ที่ถูกกล่าวถึงที่นี่ คำขอทั้งหมดมีไว้สำหรับไฟล์ดัชนีของเว็บไซต์และมีสตริงข้อความค้นหาหรือเส้นทาง เส้นทางนั้นเป็น URL ขนาดเล็กที่บอกให้แอปพลิเคชันของคุณสร้างเนื้อหา

<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
    http://dev.example.com/index.php/my:whacky:url
</a>

ข้อดีเส้นทาง:

1. ข้อดีทั้งหมดของ URL ที่แน่นอน
2. ใช้อักขระใด ๆ ใน URL
3. ควบคุมได้ดี (ดีสำหรับ SEO)
4. ความสามารถในการสร้าง URL อัลกอริทึม สิ่งนี้ช่วยให้สามารถกำหนดค่า URL ได้ การเปลี่ยนแปลง URL เป็นการเปลี่ยนแปลงครั้งเดียวในไฟล์เดียว
5. ไม่จำเป็นต้องมี 404 ไม่พบ เส้นทางสำรองสามารถแสดงแผนที่ไซต์หรือหน้าข้อผิดพลาด
6. ความปลอดภัยที่สะดวกในการเข้าถึงไฟล์แอปพลิเคชันทางอ้อม คำแถลงยามสามารถทำให้แน่ใจได้ว่าทุกคนมาถึงช่องทางที่เหมาะสม
7. การปฏิบัติจริงในแนวทาง MVC

ของฉัน

คนส่วนใหญ่จะใช้ประโยชน์จากทั้งสามรูปแบบในโครงการของพวกเขาในทางใดทางหนึ่งหรืออื่น ๆ กุญแจสำคัญคือการเข้าใจพวกเขาและเลือกหนึ่งที่เหมาะสมที่สุดสำหรับงาน

หากเป็นการใช้ภายในเว็บไซต์ของคุณควรใช้ URL สัมพัทธ์เช่นนี้หากคุณต้องการย้ายเว็บไซต์ไปยังชื่อโดเมนอื่นหรือเพียงแค่ดีบักในเครื่องคุณก็สามารถทำได้

ดูสิ่งที่ stackoverflow กำลังทำอยู่ (ctrl + U ใน firefox):

<a href="/users/recent/90691"> // Link to an internal element

ในบางกรณีพวกเขาใช้ URL แบบสัมบูรณ์:

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

... แต่นี่เป็นเพียงแนวทางปฏิบัติที่ดีที่สุดในการปรับปรุงความเร็ว ในกรณีของคุณมันดูไม่เหมือนว่าคุณกำลังทำอะไรแบบนั้นดังนั้นฉันจะไม่ต้องกังวลกับมัน

ฉันจะต้องไม่เห็นด้วยกับคนส่วนใหญ่ที่นี่

ฉันคิดว่ารูปแบบ URL สัมพัทธ์นั้น "ดี" เมื่อคุณต้องการให้บางสิ่งบางอย่างทำงานได้อย่างรวดเร็วและไม่คิดนอกกรอบโดยเฉพาะถ้าโครงการของคุณมีขนาดเล็กและมีนักพัฒนาน้อย (หรือเพียงแค่ตัวคุณเอง)

อย่างไรก็ตามเมื่อคุณเริ่มทำงานกับระบบไขมันขนาดใหญ่ที่คุณเปลี่ยนโดเมนและโปรโตคอลตลอดเวลาฉันเชื่อว่าวิธีการที่สง่างามกว่านั้นเป็นไปตามลำดับ

เมื่อคุณเปรียบเทียบ URL แบบสัมบูรณ์และแบบสัมพัทธ์ในสาระสำคัญ Absolute จะชนะ ทำไม? เพราะมันจะไม่ทำลาย เคย. URL ที่แน่นอนเป็นสิ่งที่มันบอกว่ามันเป็น การดักจับคือเมื่อคุณต้องจัดการ URL ที่แน่นอนของคุณ

วิธีที่อ่อนแอในการเชื่อมโยง URL ที่แน่นอนเป็นการยากที่จะเข้ารหัส URL ทั้งหมด ไม่ใช่ความคิดที่ดีและอาจเป็นสาเหตุของการที่ผู้คนมองว่าพวกเขาเป็นอันตราย / ชั่วร้าย / น่ารำคาญที่ต้องรักษา วิธีที่ดีกว่าคือการเขียนเครื่องมือสร้าง URL ที่ใช้งานง่าย สิ่งเหล่านี้เขียนได้ง่ายและมีประสิทธิภาพอย่างไม่น่าเชื่อ -ตรวจจับโปรโตคอลของคุณโดยอัตโนมัติง่ายต่อการกำหนดค่า (ตั้งค่า URL หนึ่งครั้งสำหรับแอปทั้งหมด) และอื่น ๆ และมันจะฉีดโดเมนของคุณเอง สิ่งที่ดีเกี่ยวกับเรื่องนี้: คุณเขียนโค้ดโดยใช้ URL สัมพัทธ์และในขณะใช้งานแอปพลิเคชันจะแทรก URL ของคุณในรูปแบบสมบูรณ์แบบทันที น่ากลัว

เมื่อดูว่าไซต์สมัยใหม่ทั้งหมดใช้งานแบ็คเอนด์แบบไดนามิกในทางปฏิบัติอย่างไรมันเป็นเรื่องที่ดีที่สุดที่เว็บไซต์ดังกล่าวจะทำเช่นนั้น URL แบบสัมบูรณ์ทำมากกว่าทำให้คุณมั่นใจว่าพวกเขาชี้ไปที่ใดพวกเขายังสามารถปรับปรุงประสิทธิภาพการทำ SEO

ฉันอาจเพิ่มว่าอาร์กิวเมนต์ที่ URL แบบสัมบูรณ์กำลังจะเปลี่ยนความเร็วในการโหลดของหน้าเว็บเป็นเรื่องโกหก หากโดเมนของคุณมีน้ำหนักมากกว่าสองสามไบต์และคุณใช้โมเด็ม dialup ในปี 1980 แน่นอน แต่นั่นไม่ใช่กรณีอีกต่อไป https://stackoverflow.com/คือ 25 ไบต์ในขณะที่ไฟล์ "topbar-sprite.png" ที่ใช้สำหรับพื้นที่นำทางของไซต์มีน้ำหนัก 9+ kb นั่นหมายความว่าข้อมูล URL เพิ่มเติมคือ. 2% ของข้อมูลที่โหลดเมื่อเปรียบเทียบกับไฟล์สไปรต์และไฟล์นั้นไม่ถือเป็นประสิทธิภาพที่ยิ่งใหญ่

ภาพพื้นหลังขนาดใหญ่ที่ไม่ได้เพิ่มประสิทธิภาพและไม่เต็มหน้ามีแนวโน้มที่จะลดความเร็วในการโหลดลง

โพสต์ที่น่าสนใจเกี่ยวกับสาเหตุที่ไม่ควรใช้ URL สัมพัทธ์อยู่ที่นี่: http://yoast.com/relative-urls-issues/

ยกตัวอย่างเช่นปัญหาที่อาจเกิดขึ้นกับญาติ ๆ คือบางครั้งการแมปเซิร์ฟเวอร์ (โปรดระลึกถึงโครงการใหญ่ที่ยุ่งเหยิง) ไม่ตรงกับชื่อไฟล์และนักพัฒนาอาจสันนิษฐานเกี่ยวกับ URL สัมพัทธ์ที่ไม่ได้เป็น จริง ฉันเพิ่งเห็นว่าวันนี้ในโครงการที่ฉันเปิดอยู่และมันทำให้ทั้งหน้าลดลง

หรืออาจเป็นนักพัฒนาซอฟต์แวร์ลืมสลับตัวชี้และ Google ก็ทำดัชนีสภาพแวดล้อมการทดสอบทั้งหมดของคุณทันที อ๊ะเนื้อหาที่ซ้ำกัน (ไม่ดีสำหรับ SEO!)

แอบโซลูทอาจเป็นอันตรายได้ แต่เมื่อใช้อย่างถูกต้องและในวิธีที่ไม่สามารถทำลายสิ่งปลูกสร้างของคุณได้การพิสูจน์แล้วว่าเชื่อถือได้มากขึ้น ดูบทความด้านบนซึ่งให้เหตุผลมากมายว่าทำไมตัวสร้าง URL ของ Wordpress นั้นยอดเยี่ยมมาก

:)

ในกรณีส่วนใหญ่ URL ที่เกี่ยวข้องเป็นวิธีที่จะไปพวกเขาจะพกพาโดยธรรมชาติซึ่งหมายความว่าถ้าคุณต้องการที่จะยกเว็บไซต์ของคุณและทำให้คนที่มันจะทำงานได้ทันทีลดการดีบักชั่วโมง

มีบทความที่น่าสนใจเกี่ยวกับ URL สัมพัทธ์กับสัมบูรณ์ลองดูสิ

URL ที่ว่าเริ่มต้นด้วยโครงการ URL และรูปแบบเฉพาะส่วน ( http://, https://, ftp://ฯลฯ ) เป็น URL แบบเต็ม

URL อื่นใด ๆ คือ URL สัมพัทธ์และต้องการ URL พื้นฐานซึ่ง URL สัมพัทธ์ได้รับการแก้ไขจาก (และขึ้นอยู่กับ) ซึ่งเป็น URL ของทรัพยากรที่ใช้ในการอ้างอิงหากไม่ได้ประกาศไว้เป็นอย่างอื่น

ลองดูที่RFC 2396 - ภาคผนวก Cสำหรับตัวอย่างการแก้ไข URL สัมพัทธ์

สมมติว่าคุณมีเว็บไซต์ www.yourserver.com ในรูทไดเร็กทอรีสำหรับเอกสารเว็บคุณมีรูปภาพย่อยไดเร็กตอยและคุณมี myimage.jpg

URL ที่แน่นอนกำหนดตำแหน่งที่แน่นอนของเอกสารตัวอย่างเช่น:

http://www.yourserver.com/images/myimage.jpg

URL สัมพัทธ์จะกำหนดตำแหน่งที่สัมพันธ์กับไดเรกทอรีปัจจุบันตัวอย่างเช่นเมื่อคุณอยู่ในสารบบเว็บรูทภาพของคุณอยู่ใน:

images/myimage.jpg

(เทียบกับไดเรกทอรีรูตนั้น)

คุณควรใช้ URL ที่เกี่ยวข้องทุกครั้งที่เป็นไปได้ หากคุณย้ายไซต์ไปที่ www.anotherserver.com คุณจะต้องอัปเดต URL สัมบูรณ์ทั้งหมดที่ชี้ไปที่ www.yourserver.com ส่วนที่เกี่ยวข้องจะยังคงทำงานเหมือนเดิม

สำหรับทุกระบบที่สนับสนุนการแก้ปัญหา URI ที่เกี่ยวข้องทั้ง URI ที่เกี่ยวข้องและสัมบูรณ์จะให้บริการในเป้าหมายเดียวกันนั่นคือการอ้างอิง และพวกเขาสามารถใช้แทนกันได้ ดังนั้นคุณสามารถตัดสินใจในแต่ละกรณีแตกต่างกัน ในทางเทคนิคพวกเขาให้การอ้างอิงเดียวกัน

เพื่อความแม่นยำกับ URI ที่เกี่ยวข้องแต่ละรายจะมี URI สัมบูรณ์อยู่แล้ว และนั่นคือ base-URI ที่ URI ที่เกี่ยวข้องได้รับการแก้ไข ดังนั้น URI แบบสัมพัทธ์จึงเป็นคุณลักษณะที่อยู่เหนือสุดของ URIs แบบสัมบูรณ์

และนั่นก็เป็นเหตุผลว่าทำไมเมื่อเทียบกับ URIs คุณสามารถทำอะไรได้มากกว่ากับ URI สัมบูรณ์เพียงอย่างเดียว - นี่เป็นสิ่งสำคัญอย่างยิ่งสำหรับเว็บไซต์แบบคงที่

ผลเชิงบวกเหล่านี้ของการแก้ปัญหา URI ที่เกี่ยวข้องสามารถนำไปใช้ในการพัฒนาเว็บแอปพลิเคชันแบบไดนามิกได้เช่นกัน URIs ที่ไม่ยอมให้คำแนะนำแบบสัมบูรณ์ยังง่ายต่อการรับมือกับในสภาพแวดล้อมแบบไดนามิกดังนั้นสำหรับนักพัฒนาบางคนที่ไม่แน่ใจเกี่ยวกับการแก้ปัญหา URI และวิธีการนำไปใช้และจัดการอย่างถูกต้อง (ไม่ใช่ว่าง่ายเสมอ) มักเลือกใช้สัมบูรณ์ URIs ในส่วนไดนามิกของเว็บไซต์เนื่องจากสามารถแนะนำคุณสมบัติแบบไดนามิกอื่น ๆ (เช่นตัวแปรการกำหนดค่าที่มีคำนำหน้า URI) เพื่อแก้ไขความยืดหยุ่น

แล้วประโยชน์ในการใช้ URI แบบสัมบูรณ์คืออะไร ในทางเทคนิคแล้วมันมีไม่ได้ แต่อย่างหนึ่งที่ฉันพูดว่า: URI ที่สัมพันธ์กันนั้นซับซ้อนกว่าเพราะพวกมันต้องได้รับการแก้ไขเทียบกับที่เรียกว่า base-URI แบบสัมบูรณ์ แม้ความละเอียดจะถูกกำหนดอย่างเคร่งครัดมาหลายปีคุณอาจใช้งานไคลเอ็นต์ที่มีข้อผิดพลาดในการแก้ปัญหา URI เนื่องจาก URI สัมบูรณ์ไม่ต้องการความละเอียดใด ๆ การใช้ UR สัมบูรณ์จึงไม่มีความเสี่ยงในการทำงานกับพฤติกรรมของไคลเอ็นต์ที่ผิดปกติด้วยการแก้ไข URI ที่สัมพันธ์กัน ดังนั้นความเสี่ยงนั้นสูงเพียงใด? มันหายากมาก ฉันรู้เกี่ยวกับอินเทอร์เน็ตเบราว์เซอร์เดียวที่มีปัญหาเกี่ยวกับการแก้ปัญหา URI ที่เกี่ยวข้อง และนั่นก็ไม่ได้โดยทั่วไป แต่เฉพาะในกรณีที่ (คลุมเครือ) มาก

ถัดจากไคลเอ็นต์ HTTP (เบราว์เซอร์) อาจซับซ้อนกว่าสำหรับผู้เขียนเอกสารหรือรหัสไฮเปอร์เท็กซ์เช่นกัน ที่นี่ URI แบบสัมบูรณ์มีประโยชน์ที่จะทดสอบได้ง่ายขึ้นเนื่องจากคุณสามารถป้อนได้ตามที่อยู่ในแถบที่อยู่ของเบราว์เซอร์ อย่างไรก็ตามหากไม่ใช่เพียงงานหนึ่งชั่วโมงคุณจะได้รับประโยชน์มากขึ้นจากการเข้าใจการจัดการ URI แบบสัมบูรณ์และแบบสัมพัทธ์เพื่อให้คุณสามารถใช้ประโยชน์จากการเชื่อมโยงแบบสัมพัทธ์ได้

ฉันขอแนะนำ URL สัมพัทธ์อย่างเต็มที่สำหรับการชี้บิตของไซต์เดียวกันไปยังบิตอื่น ๆ ของไซต์เดียวกัน

อย่าลืมว่าการเปลี่ยนแปลง HTTPS แม้ว่าในเว็บไซต์เดียวกันจะต้องมี URL ที่แน่นอน