เฟรมเวิร์กเว็บแอ็พพลิเคชันสมัยใหม่มีวิธีการอย่างไรและทำไมจึงพัฒนาเพื่อแยกเส้นทาง URL จากระบบไฟล์

67

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

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

คำถาม

เรื่องนี้เกิดขึ้นได้อย่างไรและทำไมเป็นเรื่องธรรมดา? มันเป็นอย่างไรและทำไมจึงตัดสินใจว่ามัน "ดีกว่า" ถึงจุดที่การละทิ้งแนวทางตรงไปยังไฟล์ครั้งหนึ่งเคยเป็นเรื่องธรรมดา?

คำตอบอื่น ๆ

มีคำตอบที่คล้ายกันที่นี่ซึ่งเป็นแนวคิดเกี่ยวกับเส้นทางและข้อดีและข้อเสียบางประการ: ด้วยกรอบงาน PHP ทำไมแนวคิด "เส้นทาง" จึงถูกใช้?

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

นอกจากนี้ผลประโยชน์และข้อเสียดังกล่าวส่วนใหญ่ดูเหมือนจะไม่สำคัญพอที่จะรับประกันการเปลี่ยนแปลงระดับโลก ประโยชน์เพียงอย่างเดียวที่ฉันเห็นได้จากการเปลี่ยนแปลงนี้คือการซ่อนระบบไฟล์ / โฟลเดอร์จากผู้ใช้ปลายทางและขาด?param=value&param2=valueซึ่งทำให้ URL ดูสะอาดตา แต่นั่นเป็นเหตุผลเดียวที่ทำให้เกิดการเปลี่ยนแปลง? และถ้าใช่ทำไมเหตุผลเหล่านั้นถึงซ่อนอยู่?

ตัวอย่าง:

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

Zend Expressive

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework co.th / Zend แสดงออก / คุณสมบัติ / เราเตอร์ / zf2 /

Zend Framework

https://docs.zendframework.com/zend-mvc/routing/

Laravel

https://laravel.com/docs/5.5/routing

CakePHP

https://book.cakephp.org/3.0/en/development/routing.html

web-applications history routing

— เดนนิส
แหล่งที่มา

14

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

— RSM

2

@rsm ฉันมีปฏิกิริยาแรกคล้ายกัน แต่ในความคิดต่อไปมันเป็นสิ่งที่ทำในหลายภาษาและแพลตฟอร์มที่นำไปสู่การเป็นแหล่งช่องโหว่ที่พบบ่อยมาก

— JimmyJames

6

@rsm, นี่อาจเห็นได้ชัดกว่าในกรอบ PHP แต่จะใช้วิธีอื่น - ในบางช่วงเวลาก่อนที่กรอบการทำงานใด ๆ ติดอยู่กับที่ไม่ว่าจะเป็น ASP, .NET, PHP, JSP, ฯลฯ เว็บส่วนใหญ่ใช้โดยตรง - วิธีการเป็นไฟล์ ทำไมกรอบเหล่านี้ทั้งหมดจึงพัฒนาเพื่อใช้วิธีแยกสองส่วน ในทางเทคนิคแล้ววิธีการตรงไปยังไฟล์ยังคงเป็นไปได้และฉันมั่นใจว่ากรอบงานที่ทันสมัยสามารถใช้งานได้ หรือพวกเขาสามารถ? บางทีพวกเขาไม่สามารถและอาจมีเหตุผลที่ดีว่าทำไมพวกเขาไม่? อะไรคือเหตุผลเหล่านั้น .. พวกเขาไม่ได้มีวิธีหรือปลั๊กอินในการทำเช่นนี้พวกเขาเพียงกำจัดให้สิ้นซากโดยตรงไปยังไฟล์ทั้งหมด

— Dennis

2

สิ่งนี้ (บางส่วน) ยังเกี่ยวกับการดู URL (ตัวระบุวิธีการค้นหาทรัพยากร) เป็น URI (และตัวระบุ ) หรือไม่

— Hagen von Eitzen

2

การอ่านที่เกี่ยวข้องจากประวัติศาสตร์โบราณ: Cool URIs ไม่เปลี่ยนแปลง - Tim Berners-Lee, 1998

— Michael Hampton

72

ในรูปแบบพื้นฐานที่สุดเว็บไซต์ให้บริการไฟล์คงที่ การแม็พพา ธ URL กับพา ธ ไฟล์เป็นตัวเลือกที่ชัดเจนที่สุด โดยพื้นฐานแล้วมันเป็นไซต์ FTP แบบอ่านอย่างเดียว

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

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

เมื่อคุณเริ่มใช้ภาษาที่คอมไพล์ขั้นสูงยิ่งขึ้นคุณจะหย่าร้างจากตำแหน่งไฟล์มากยิ่งขึ้น

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

แต่ฉันคิดว่าการเปลี่ยนแปลงของทะเลที่แท้จริงเกิดขึ้นเมื่อผู้ใช้ต้องการกำจัดนามสกุลไฟล์ออกจากเส้นทาง การ myPage.asp หรือ myPage.php เป็นสิ่งที่ทำให้ผู้คนสับสน 'ปกติ' และเข้าแทรกแซงด้วย SEO

เนื่องจากผู้ใช้เห็นเส้นทางมันได้กลายเป็นส่วนหนึ่งของ UI ของเว็บและดังนั้นจึงต้องปราศจากข้อ จำกัด ทางเทคนิคใด ๆ เราสูญเสีย 'www' และทุกอย่างก็คือ '.com' URL หลายรายการจะชี้ไปที่หน้าเดียวกัน

หากฉันทำเงินได้มากขึ้นด้วย mydomain.com/sale vs www.mydomain.co.uk/products/sale.aspx แสดงว่าฉันไม่ต้องการข้อ จำกัด ทางเทคนิคใด ๆ

— Ewan
แหล่งที่มา

7

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

— Caius Jard

20

@CaiusJard ที่เป็นส่วนหนึ่งของมัน แต่อีกส่วนหนึ่งคือความไม่เชื่อเรื่องพระเจ้า - แทนที่ file.html ในเส้นทางของเราเราไม่ต้องการที่จะติดอยู่กับสวิตช์อื่นในภายหลัง (ตัวอย่างเช่น file.phtml เป็น file.php หรือแม้กระทั่งเพื่อ file.asp) แต่เนื่องจากเราแยก URL และเส้นทางของระบบไฟล์ (โดยใช้การเราต์หรืออะไรก็ตาม) เพื่อเข้าถึงทรัพยากรที่สร้างจากบันทึกฐานข้อมูลและ / หรือแหล่งอื่น ๆ เหตุใดจึงมีส่วนขยายใน URL เลย

— HorusKol

39

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

— เชน

7

ที่น่าสนใจคือไม่แนะนำให้มีนามสกุลไฟล์ใน URI ดังนั้นจึงควรแยกออกจากระบบไฟล์ก่อน การอ้างอิงที่เก่าที่สุดที่ฉันสามารถหาได้คือจากปี 1998ซึ่งจริงแล้วมีการพัฒนาส่วนใหญ่ที่อธิบายไว้ในคำตอบนี้

— Konrad Rudolph

8

ในสมัยก่อน mydomain.com/sale ยังคงทำงาน; มันเปลี่ยนเส้นทางไปที่ / sale / และโหลดได้ดี (หน้าของคุณคือ mydomain.com/sale/index.aspx แต่ไม่มีใครเห็น index.aspx เลย)

— Joshua

39

คุณสามารถมองไปที่กระดาษสีขาวโดยรอยฟีลดิงในการดำเนินการของรัฐโอนเงิน (REST)เกี่ยวกับการเมื่อและทำไม เฟรมเวิร์กแรกที่ฉันทราบว่าสร้างความแตกต่างระหว่างทรัพยากรและไฟล์คือ Ruby on Rails - แนะนำแนวคิดของ URL ไปยังการกำหนดเส้นทางโค้ด

แนวคิดหลักที่อยู่เบื้องหลัง REST ที่มีการเปลี่ยนแปลง ได้แก่ :

URL แสดงถึงทรัพยากร
ทรัพยากรนั้นสามารถมีตัวแทนได้หลายคน
URL ไม่ควรแตกหากแอปพลิเคชันได้รับการปรับโครงสร้าง
แอปพลิเคชันควรโอบกอดไร้สัญชาติของเว็บ

ข้อเสียเปรียบหลักของการมีไฟล์ให้บริการโดยตรงจาก URL คือคุณพบปัญหาต่อไปนี้:

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

ฉันคิดว่ามันเป็นสิ่งสำคัญที่จะให้สมดุลที่เป็นธรรมเช่นกัน:

ทรัพยากรไม่สำคัญเท่ากัน นั่นเป็นเหตุผลที่คุณยังคงมีแหล่งข้อมูลตามสไตล์โดยตรง (CSS, JavaScript / EcmaScript, รูปภาพ)
มีการปรับแต่ง REST เช่นHATEOASที่รองรับแอปหน้าเดียวได้ดียิ่งขึ้น

— Berin Loritsch
แหล่งที่มา

เมื่อคุณพูดว่าการเป็นตัวแทนคุณหมายถึงสิ่งต่างๆเช่น JSON / HTML / TEXT / etc? ฉันไม่คุ้นเคยกับ REST แต่ฉันคิดว่าแม้กับ REST คุณจะต้องมีทริกเกอร์เพื่อเปลี่ยนการตอบสนองบางอย่าง ...

— Dennis

@ เดนนิสใช่ HTTP มีส่วนหัวจำนวนมากที่สามารถใช้บอกใบ้ในรูปแบบที่ต้องการได้ ( developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation ) และ REST คือทั้งหมดที่เกี่ยวกับการรับความแข็งแกร่งของ HTTP อย่างไรก็ตามมันก็ไม่ใช่เรื่องแปลกที่แอพจะมีวิธีการที่เป็นกรรมสิทธิ์ในการเจรจาต่อรองเนื้อหาที่ต้องการ

— Berin Loritsch

5

CGI (1993), Servlets (1997) และ JSP (1999) มักจะแยก URL ออกจากระบบไฟล์และ REST (2000) ล่วงหน้า อย่างไรก็ตามคำตอบนี้ถูกต้องในการระบุสาเหตุของความนิยมของรูปแบบการออกแบบ: REST, Java Struts และ Ruby on Rails มีอิทธิพลอย่างมากต่อความนิยมในศตวรรษที่ 21 ของการแยกทรัพยากรออกจากการเป็นตัวแทน

— dcorking

1

อ้างอิงจากเอกสารของ Fielding "ฉบับพิมพ์ครั้งแรกของ REST ได้รับการพัฒนาระหว่างตุลาคม 2537 และสิงหาคม 2538"

— คอนเนอร์

1

@dcorking, CGI ในขณะนั้นไม่ได้แยก URL ออกจากไฟล์มันแค่เรียกใช้ไฟล์แทน 9 ครั้งจาก 10 เซิร์ฟเวอร์อาจเป็นคู่ที่ใกล้เคียงที่สุด แต่ถ้าคุณพูดถึงแนวคิดของเส้นทางและมีพื้นที่ url ที่ออกแบบมาที่มาพร้อมกับ Rails และเฟรมเวิร์คเหมือนกัน

— Berin Loritsch

20

ฉันไม่คิดว่ามันเป็นสิ่งประดิษฐ์ของกรอบเว็บแอปพลิเคชันที่ทันสมัยแต่ส่วนใหญ่เป็นสิ่งประดิษฐ์ของการแสดงหน้าเว็บแบบไดนามิกโดยทั่วไป

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

แล้วยุคของการแสดงเนื้อหาแบบไดนามิกก็มาถึง สคริปต์ CGI (และทุกอย่างที่พัฒนามาจากพวกเขา) ได้สร้างหน้าเว็บขึ้นมาโดยได้รับการสนับสนุนจากฐานข้อมูลบางประเภท GET พารามิเตอร์ใน URL กลายเป็นเรื่องธรรมดาเช่นen.wikipedia.org/w/index.php?title=Path_(computing)

อย่างไรก็ตามมันเป็นมิตรต่อผู้ใช้มากกว่าที่จะมี URL ที่อ่านได้ซึ่งประกอบด้วยส่วนของเส้นทางเท่านั้น ดังนั้นแอปพลิเคชันแบบไดนามิกจึงแมปพา ธ แบบง่าย ๆ (ตัวอย่างเช่นen.wikipedia.org/wiki/Path_(computing) ) กับพารามิเตอร์และการแมปเหล่านี้จึงเป็นที่รู้จักกันในชื่อ "เส้นทาง"

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

— Bergi
แหล่งที่มา

12

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

เหตุผลหนึ่งคือกรอบงานเว็บจำนวนมากเขียนด้วยภาษาที่คอมไพล์ดังนั้นคุณไม่มีโครงสร้างไฟล์บนดิสก์เพียงjarไฟล์หรืออะไรก็ตาม ภาษาตีความตีความยืมความคิดที่พวกเขาชอบจากคนที่รวบรวม

https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routesเหตุผลหนึ่งก็คือความปรารถนาสำหรับความหมายเส้นทางแบบไดนามิกมากขึ้นเช่น เห็นได้ชัดว่าคุณไม่ต้องการ/var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpไฟล์ คุณใช้เพื่อสร้างกฎการเขียน url ใหม่ในการกำหนดค่าเว็บเซิร์ฟเวอร์เพื่อสร้างเส้นทางเช่นนี้ ตอนนี้มันเป็นเพียงการเปลี่ยนรหัสซึ่งทำได้ง่ายกว่ามาก

— Karl Bielefeldt
แหล่งที่มา

คุณไม่จำเป็นต้องเขียน url ใหม่สำหรับตัวอย่างนั้น

— Yay295

1

มันจัดการโดยรหัสที่รับรู้ส่วนแรกของเส้นทางและใช้หมายเลข / 363517 / เพื่อค้นหาคำถามในฐานข้อมูล ไม่มีอะไรเกี่ยวข้องกับเว็บเซิร์ฟเวอร์ แต่เป็นแอปพลิเคชัน ...

— Crawford Will

11

เหตุผลหลักน่าจะเป็นที่วิธีการแมป URIs นี้กับพา ธ ไฟล์ทำให้เกิดการเผยแพร่ข้อมูลจำนวนมากโดยไม่ตั้งใจผ่านทางFile Path Traversal

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

นี่ไม่ใช่ปัญหา PHP เท่านั้น เป็นหลักฐานที่นี่เป็นส่วนที่เกี่ยวข้องของคู่มือแข็ง Apache

— JimmyJames
แหล่งที่มา

1

ทำไมต้องลงคะแนน

— JimmyJames

8

ฉันไม่สามารถตอบอุตสาหกรรมได้ แต่ฉันสามารถบอกคุณได้ว่าเหตุใดฉันจึงย้ายออกจากระบบไฟล์ URL = ย้อนกลับไปในช่วงต้นปี 2000 สู่ 'เส้นทาง' เสมือน

ทำงานกับ PHP 'old school' หากคุณมีหน้า PHP 1,000 หน้าคุณจะมีไฟล์ PHP 1,000 ไฟล์ที่แสดงหน้าเหล่านั้น ส่วนหัว / ส่วนท้ายที่ซ้ำกันหนึ่งรายการรวมถึงและตรรกะอื่น ๆ ตอนนี้สมมติว่าคุณต้องเปลี่ยนสิ่งนั้น ตอนนี้คุณมีเรื่องยุ่ง ๆ อยู่ในมือแล้ว! คุณต้องเปลี่ยนไฟล์ทั้งหมด 1,000 ไฟล์หรือจบด้วยความสับสนในโค้ดส่วนหัว / ท้ายกระดาษเพื่อจัดการเคสทั้งหมด การใช้เส้นทางเสมือนตรรกะส่วนหัว / ส่วนท้ายของคุณตรรกะการเชื่อมต่อฐานข้อมูลและการเริ่มต้นอื่น ๆ จะรวมอยู่หนึ่งครั้งระยะเวลา ดีกว่ามากที่จะทำงานกับ

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

สุดท้าย (แม้ว่าจะมีเหตุผลอื่น ๆ แต่เป็นรายการสุดท้ายที่ฉันจะทำ) หน้าเว็บ 1000 หน้าเหล่านั้นแสดงรหัสที่จะซ้ำกัน ดังนั้นหลังจากการเปลี่ยนโครงสร้างเป็นชุดคลาสและแม่แบบที่เหมาะสมรหัสนั้นง่ายมากและคุณสามารถทำทุกอย่างที่คุณต้องการโดยไม่ต้องมีไฟล์ 1,000 ไฟล์

— GrandmasterB
แหล่งที่มา

คุณพูดได้มากกว่านี้ไหมว่าทำไมคุณถึงลงเอยด้วยรหัสที่น่าเกลียดมาก? ฉันสามารถเห็นความต้องการในการเปลี่ยนแปลง 1,000 ไฟล์ (สมมติว่ามันคือการปรับปรุงส่วนหัว / ส่วนท้ายรวมถึง) แต่คุณหมายถึงอะไรโดยการสับสนของรหัสน่าเกลียด?

— Dennis

ดูย่อหน้าที่ฉันเพิ่งเพิ่ม แต่โดยทั่วไปเมื่อคุณขยายรหัสส่วนหัว / ท้ายกระดาษ / การเริ่มต้นเพื่อจัดการกรณีเพิ่มเติมโดยเฉพาะอย่างยิ่งถ้าคุณรวมไฟล์อื่น ๆ แบบมีเงื่อนไข (มันเป็นนิสัยที่ไม่ดี แต่โปรแกรมเมอร์ PHP จำนวนมากก็ทำ) .

— GrandmasterB

5

ฉันจะไม่ลงรายละเอียดมากเกินไปว่าทำไมการแยกนี้มีประโยชน์ อาร์กิวเมนต์หลักคือมันแยกซีแมนทิกส์ (คุณพยายามเข้าถึงอะไร) จากการใช้งานพื้นฐาน

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

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

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

— doubleyou
แหล่งที่มา

1

RFCs ได้สร้างแนวคิดตั้งแต่เริ่มต้นด้วย URIs (ที่ไม่ได้แนบซีแมนทิกส์กับส่วนโลคัล) และ URL เป็นกรณีพิเศษที่แนะนำซีแมนทิกส์คล้ายพา ธ เพื่อให้เอกสาร HTML ใช้ลิงก์ที่สัมพันธ์กับเอกสาร URL ฐาน

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

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

— Simon Richter
แหล่งที่มา

1

ในตอนแรก URL ถูกแม็พกับพา ธ ไฟล์บนเซิร์ฟเวอร์โดยตรงเพราะทำได้ง่ายและไม่มีวิธีอื่นในการทำเช่นนั้นใช่ไหม หากฉันขอ/path/to/index.phpฉันจะ/path/to/index.phpเริ่มต้นจากไดเรกทอรีรากของเว็บไซต์ (โดยปกติจะไม่ใช่เซิร์ฟเวอร์เองเว็บไซต์ควรถูกเก็บไว้ในไดเรกทอรีหรือไดเรกทอรีย่อยต่อไป)

หลังจากนั้นสองสามปีเราก็เริ่มเรียนรู้เกี่ยวกับการเขียนใหม่ซึ่งให้บริการทรัพยากรที่แตกต่างจากที่ถามมาอย่างเห็นได้ชัด จริงสามารถให้บริการได้/request/path/to/index.php/response/path/to/index.php

index.phpเคล็ดลับก็คือการหลบซ่อนตัวอยู่ ถ้าฉันขอ/index.php?foo=bar&baz=quxเซิร์ฟเวอร์สามารถตอบสนองโดยการซ่อนตัวอยู่index.phpเช่นดังนั้น: /?foo=bar&baz=quxทั้งหมดในขณะที่จริงการให้บริการindex.phpอยู่แล้ว

ขั้นตอนต่อไปซึ่งเป็นขนาดใหญ่ที่สำคัญคือการที่เราเรียนรู้ที่จะเปลี่ยนเส้นทางทั้งหมด URL /index.phpที่จะ ดังนั้นตอนนี้จะถูกนำไปอย่างเงียบ/path/to/some/page ๆ /index.php?path/to/some/pageนี่เป็นบิตที่ยุ่งยากเพราะโดยปกติแล้วเครื่องหมายสแลชแต่ละอันจะแสดงไดเรกทอรีย่อยใหม่ แต่ในกรณีนี้เว็บเซิร์ฟเวอร์ได้รับการกำหนดค่าให้ส่งพา ธ เป็นพารามิเตอร์แทนที่จะมองเข้าไปในนั้น

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

มันจะเปลี่ยนเว็บไซต์แอปของคุณเป็นแสนหรือพัน (ถ้าคุณคิดว่าแต่ละไฟล์เป็นแอพของตัวเอง) เป็นแอพเดียวที่ซับซ้อนกว่า แต่มีความสอดคล้องมากกว่า

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

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

— CJ เดนนิส
แหล่งที่มา

-1

ในฐานะที่เป็น webdev เป็นเวลานานฉันคิดว่าการถือกำเนิดของการควบคุมประวัติที่ไม่มีการนำทาง ( history.pushState()) รอบเวลาของ HTML5 ทำให้สิ่งนี้เป็นจริง ก่อนหน้านั้นคุณต้องโหลดหน้านี้ซ้ำเพื่ออัปเดตแถบ URL เว้นแต่คุณจะอัปเดตชิ้นส่วน ( /path#fragment) เท่านั้น ส่วนนี้ไม่สามารถมองเห็นได้กับเซิร์ฟเวอร์ (ไม่ได้กำหนดเส้นทาง) ดังนั้นวิธีเดียวที่จะรีเฟรชหรือบุ๊กมาร์กหน้าแบบไดนามิกคือผ่าน JavaScript

สิ่งนี้มีนัยสำคัญสำหรับ SEO และนำ Google ไปสู่การพัฒนาschema "hashbang"ที่ไม่ค่อยได้ใช้ซึ่งต้องการการแมปแฮชแบบไดนามิกฝั่งเซิร์ฟเวอร์กับ URL ทางกายภาพ สิ่งนี้ไม่สะดวกและไม่เป็นที่นิยมในหมู่หุ่นยนต์นำไปสู่ความจริง (เท็จ): "แมงมุมไม่สามารถรวบรวมข้อมูลอาแจ็กซ์" แต่ประโยชน์ของเนื้อหาอาแจ็กซ์นั้นเป็นรูปธรรม: ลองใช้ google maps โดยไม่มี JS เช่น

โซลูชันเป็นวิธีอัปเดตแถบ URL ด้วยค่าที่สามารถทำมิเรอร์บนเซิร์ฟเวอร์ (อนุญาตให้บุ๊กมาร์กและรีเฟรช JS-less) โดยไม่ต้องโหลดหน้าซ้ำ เมื่อความสามารถนี้พร้อมใช้งานผู้พัฒนาสามารถ "นำทาง" ไซต์โดยเพียงแค่อัปเดต "ส่วนเนื้อหาหลัก" แถบ URL และ breadcrumb นี่หมายความว่า JS + CSS ทั้งหมดไม่จำเป็นต้องมีการดึงข้อมูล + แยกวิเคราะห์ช่วยให้การถ่ายโอนแบบหน้าต่อหน้าเร็วขึ้นมาก

— dandavis
แหล่งที่มา