Làm thế nào và tại sao các khung ứng dụng web hiện đại phát triển để tách các tuyến URL khỏi hệ thống tệp?

So với khoảng 10 năm trước, tôi đã lưu ý một sự thay đổi đối với các khung sử dụng kiểu định tuyến tách riêng đường dẫn URL khỏi hệ thống tệp. Điều này thường được thực hiện với sự trợ giúp của mẫu điều khiển phía trước.

Cụ thể, khi trước đó, đường dẫn URL được ánh xạ trực tiếp vào hệ thống tệp và do đó phản ánh các tệp và thư mục chính xác trên đĩa, ngày nay, các đường dẫn URL thực tế được lập trình để được dẫn đến các lớp cụ thể thông qua cấu hình và do đó, không còn phản ánh tệp thư mục hệ thống và cấu trúc tập tin.

Câu hỏi

Làm thế nào và tại sao điều này trở nên phổ biến? Làm thế nào và tại sao nó lại quyết định rằng nó "tốt hơn" đến mức mà phương pháp tiếp cận trực tiếp với tập tin đã từng bị bỏ rơi một cách hiệu quả?

Câu trả lời khác

Có một câu trả lời tương tự ở đây đi sâu vào khái niệm tuyến đường và một số lợi ích và nhược điểm: Với các khung công tác PHP, tại sao khái niệm "tuyến đường" được sử dụng?

Nhưng nó không giải quyết các khía cạnh thay đổi lịch sử, hoặc làm thế nào hoặc tại sao sự thay đổi này dần dần xảy ra, nơi mà bất kỳ dự án mới nào hiện nay đều sử dụng mẫu kiểu định tuyến mới này và tệp trực tiếp bị lỗi thời hoặc bị bỏ rơi.

Ngoài ra, hầu hết những lợi ích và hạn chế được đề cập, dường như không đủ quan trọng để đảm bảo một sự thay đổi toàn cầu như vậy. Lợi ích duy nhất mà tôi có thể thấy khi điều khiển thay đổi này có lẽ là ẩn hệ thống tệp / thư mục khỏi người dùng cuối và cũng thiếu ?param=value&param2=value, điều này làm cho các URL trông gọn gàng hơn. Nhưng đó có phải là lý do duy nhất cho sự thay đổi? Và nếu có, tại sao những lý do đằng sau nó?

Ví dụ:

Tôi quen thuộc nhất với các khung công tác PHP và nhiều khung công tác hiện đại phổ biến sử dụng phương pháp định tuyến tách rời này. Để làm cho nó hoạt động, bạn thiết lập viết lại URL trong Apache hoặc máy chủ web tương tự, nơi chức năng ứng dụng web thường không còn được kích hoạt thông qua đường dẫn URL trực tiếp đến tệp.

Biểu cảm Zend

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework. com / zend-expressive / features / router / zf2 /

Khung Zend

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

Ấu trùng

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

CakePHP

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

Ở dạng cơ bản nhất, một trang web phục vụ các tệp tĩnh. Ánh xạ đường dẫn URL tới đường dẫn tệp là lựa chọn rõ ràng nhất; về cơ bản, đó là một trang FTP chỉ đọc.

Sau đó, mọi người muốn thay đổi nội dung của trang với một số kịch bản. Cách dễ nhất là nhúng ngôn ngữ script vào trang và chạy nó thông qua trình thông dịch. Một lần nữa, với đường dẫn đã có sẵn -> định tuyến đường dẫn tệp, điều này đủ đơn giản.

Nhưng thực sự, bạn đang chạy tệp đó như là một đối số cho trình thông dịch. Bạn phải xác định khi nào yêu cầu dành cho một tệp tĩnh và khi nào thì yêu cầu phải giải thích.

Khi bạn bắt đầu sử dụng các ngôn ngữ được biên dịch nâng cao hơn, bạn thậm chí còn ly dị hơn với vị trí tệp.

Thêm vào đó, máy chủ web của bạn đã lưu các tệp tĩnh và thực hiện tất cả các loại tối ưu hóa, điều đó có nghĩa là việc nhấn hệ thống tệp là ngoại lệ thay vì quy tắc. Tại thời điểm này, đường dẫn hệ thống tệp liên kết cũ gây nhiều trở ngại hơn là trợ giúp.

Nhưng tôi nghĩ rằng sự thay đổi thực sự trên biển đã đến khi người dùng muốn thoát khỏi phần mở rộng tập tin khỏi đường dẫn. Nhận myPage.asp hoặc myPage.php là điều khiến mọi người 'bình thường' bối rối và can thiệp vào SEO.

Bởi vì người dùng nhìn thấy đường dẫn, nó đã trở thành một phần của giao diện người dùng của web và do đó, nó cần phải hoàn toàn không có bất kỳ giới hạn kỹ thuật nào. Chúng tôi đã mất 'www' và hầu như mọi thứ đều là '.com'. Nhiều URL sẽ trỏ đến cùng một trang.

Nếu tôi kiếm được nhiều tiền hơn với mydomain.com/sale so với www.mydomain.co.uk/products/sale.aspx, thì tôi không muốn bất kỳ giới hạn kỹ thuật nào cản trở tôi.

Bạn có thể tìm đến một tờ giấy trắng của Roy Fielding về Chuyển giao trạng thái REpresentational (REST) về thời điểm và lý do . Khung đầu tiên tôi nhận thấy rằng sự khác biệt giữa tài nguyên và tệp là Ruby on Rails - giới thiệu khái niệm URL để định tuyến mã.

Các khái niệm chính đằng sau REST đã được chuyển đổi là:

• Một URL đại diện cho một tài nguyên
• Tài nguyên đó có thể có nhiều biểu diễn
• URL không được phá vỡ nếu ứng dụng được cấu trúc lại
• Các ứng dụng nên nắm lấy tính không trạng thái của web

Hạn chế chính của việc các tệp được URL phục vụ trực tiếp là bạn gặp phải các vấn đề sau:

• Liên kết tài nguyên liên tục bị phá vỡ khi các trang web được tổ chức lại
• Tài nguyên và đại diện gắn liền với nhau

Tôi nghĩ điều quan trọng là cung cấp một số dư công bằng:

• Không phải tất cả các nguồn lực đều có tầm quan trọng như nhau. Đó là lý do tại sao bạn vẫn có tài nguyên dựa trên kiểu được phục vụ trực tiếp (CSS, JavaScript / EcmaScript, hình ảnh)
• Có những tinh chỉnh của REST như HATEOAS hỗ trợ tốt hơn cho các ứng dụng trang đơn.

Tôi không nghĩ rằng đó là một vật phẩm của các khung ứng dụng web hiện đại , nó chủ yếu là một vật phẩm của việc phục vụ trang động nói chung.

Ngày xưa , hầu hết các trang web tĩnh, nơi một phần mềm phục vụ các tệp riêng lẻ từ hệ thống tệp theo đường dẫn của chúng. Họ đã làm như vậy chủ yếu là vì ánh xạ 1: 1 của các đường dẫn URL tới các đường dẫn hệ thống tệp (với một thư mục được chỉ định là gốc web) là lựa chọn rõ ràng, mặc dù việc viết lại URL (ví dụ để tạo chuyển hướng sau khi di chuyển tệp) cũng rất phổ biến.

Rồi đến tuổi phục vụ nội dung năng động. Các tập lệnh CGI (và mọi thứ phát triển từ chúng) đã tạo ra các trang một cách nhanh chóng, được hỗ trợ bởi một cơ sở dữ liệu nào đó. NHẬN tham số trong URL trở nên phổ biến, ví dụ en.wikipedia.org/w/index.php?title=Path_(computing) .

Tuy nhiên, sẽ thân thiện hơn khi có một URL dễ đọc chỉ bao gồm các phân đoạn đường dẫn. Vì vậy, các ứng dụng động ánh xạ các đường dẫn đơn giản (ví dụ en.wikipedia.org/wiki/Path_(computing) ) thành các tham số và các ánh xạ này được gọi là "tuyến đường".

Có lẽ cách tiếp cận này cảm thấy gần đây hơn khi nó trở nên phổ biến khi tầm quan trọng của khả năng sử dụng được công nhận rộng rãi hơn, và cũng trở thành một phần của SEO. Đây có lẽ là lý do tại sao nó được xây dựng trực tiếp vào các khung web lớn.

Một lý do là việc tải tệp từ đĩa trên mỗi yêu cầu đều chậm, vì vậy các máy chủ web bắt đầu tạo cách để lưu tệp vào bộ nhớ, sau đó nếu bạn cố gắng giữ nó trong bộ nhớ, tại sao nó lại quan trọng đĩa?

Một lý do là nhiều khung web được viết bằng các ngôn ngữ được biên dịch, do đó bạn thậm chí không có cấu trúc tệp trên đĩa, chỉ là một jartệp hoặc bất cứ thứ gì. Ngôn ngữ được giải thích mượn ý tưởng mà họ thích từ những người biên soạn.

Một lý do là mong muốn cho các tuyến đường ngữ nghĩa, năng động hơn, như thế nào https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. Rõ ràng, bạn không muốn một /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phptập tin. Bạn đã sử dụng để tạo các quy tắc viết lại url trong cấu hình máy chủ web để tạo các tuyến đường như thế này. Bây giờ nó chỉ là một thay đổi mã, hoạt động đơn giản hơn nhiều.

Một trong những lý do chính có thể là cách tiếp cận ánh xạ URI này tới đường dẫn tệp đã dẫn đến một số lượng lớn các bản phát hành dữ liệu ngẫu nhiên thông qua Đường dẫn tệp

Khi bạn ánh xạ đường dẫn đến hệ thống tệp, điều đó có nghĩa là sau đó bạn cần kiểm tra xem mọi đường dẫn mà bạn nhận được dưới dạng yêu cầu ánh xạ tới các tệp mà khách hàng có thể truy cập được. Một cách tiếp cận đơn giản để đảm bảo rằng điều đó không xảy ra là loại bỏ ánh xạ trong suốt và thực hiện nó rõ ràng hơn.

Đây không phải là vấn đề chỉ dành cho PHP. Bằng chứng ở đây là một phần có liên quan của hướng dẫn làm cứng Apache .

Tôi không thể trả lời cho ngành công nghiệp, nhưng tôi có thể cho bạn biết lý do tại sao tôi chuyển khỏi hệ thống tệp URL = vào đầu những năm 2000 theo hướng 'tuyến đường' ảo.

Làm việc với PHP của 'trường học cũ', nếu bạn có 1000 trang PHP, bạn sẽ có 1000 tệp PHP đại diện cho các trang đó. Mỗi một tiêu đề / chân trang trùng lặp bao gồm và có thể một số logic khác. Bây giờ hãy nói rằng bạn cần thay đổi điều đó. Thật là một mớ hỗn độn bây giờ bạn có trong tay của bạn! Bạn có thể phải thay đổi tất cả 1000 tệp hoặc kết thúc bằng một mớ mã rất xấu trong tiêu đề / chân trang để xử lý tất cả các trường hợp. Sử dụng các tuyến ảo, logic đầu trang / chân trang, logic kết nối cơ sở dữ liệu và khởi tạo khác được bao gồm một lần , theo chu kỳ. Tốt hơn nhiều để làm việc với.

Một lý do khác là để tránh sự mơ hồ. Khi các ứng dụng phát triển, các tiêu đề / chân trang được đưa vào trở nên phức tạp hơn. Chúng thường được lồng vào nhau bao gồm những thứ phụ thuộc vào nhiều thứ khác nhau. Trong tệp PHP cho 'trang', thường thì bạn gặp phải sự mơ hồ về việc liệu một biếnetet () hay không. Sử dụng các tuyến ảo và một ứng dụng nơi mọi thứ bạn cần được tải trên mỗi lần tải trang, bạn không còn phải lo lắng nữa.

Cuối cùng (mặc dù có những lý do khác, nhưng đó là danh sách cuối cùng tôi sẽ liệt kê), nhiều trong số 1000 trang đó đại diện cho mã sẽ được sao chép. Vì vậy, sau khi tái cấu trúc thành một tập hợp các lớp và mẫu thích hợp, mã được đơn giản hóa rất nhiều và bạn có thể làm mọi thứ bạn muốn làm mà không cần có 1000 tệp đó.

Tôi sẽ không đi vào chi tiết quá nhiều về lý do tại sao sự tách biệt này có lợi. Đối số chính là nó tách biệt ngữ nghĩa (những gì bạn thực sự đang cố gắng truy cập) từ việc thực hiện cơ bản.

Nhận thấy rằng các lợi ích vượt xa các chi phí nhất định - đó sẽ là một câu hỏi riêng biệt - không khó để hiểu tại sao nó dần được áp dụng. Tôi không nghĩ có một sự kiện duy nhất gây ra điều này, mặc dù tôi chắc chắn sẽ cởi mở để được giáo dục về điều này.

Ít nhất theo kinh nghiệm của tôi, ban đầu điều này thường được thực hiện thông qua cấu hình Apache - và có lẽ các máy chủ web khác cũng hỗ trợ điều này. Tuy nhiên, về mặt khái niệm không có lý do chính đáng tại sao máy chủ nên được giao nhiệm vụ này. Rốt cuộc, các tuyến đường là dành riêng cho ứng dụng thực tế, vì vậy sẽ rất hợp lý khi xác định chúng ở đó.

Điều này đã thay đổi trên toàn cầu, nhưng khi bạn chỉ ra, dần dần. Lý do cho điều này gần như chắc chắn là một điều rất đơn giản: những ý tưởng hay được lan truyền theo thời gian. Đây cũng là lý do tại sao không có gì ngạc nhiên khi sự thay đổi xảy ra trên toàn cầu. Không phải mọi người hợp lại và quyết định làm theo cách này. Thay vào đó, mọi dự án đều điều chỉnh cách tiếp cận này khi họ nghĩ rằng nó sẽ có ích (và các dự án không hỗ trợ cuối cùng đã biến mất).

Các RFC đã xây dựng các khái niệm từ đầu, với các URI (không gắn bất kỳ ngữ nghĩa nào với phần cục bộ) và URL là một trường hợp đặc biệt giới thiệu ngữ nghĩa giống như đường dẫn để cho phép các tài liệu HTML sử dụng các liên kết liên quan đến tài liệu URL cơ sở.

Việc triển khai rõ ràng là ánh xạ phần cục bộ của URL trực tiếp vào hệ thống tệp, vì vậy đây là cách thiết lập đơn giản đã thực hiện - cho dù bạn sử dụng cơ sở dữ liệu quan hệ chuyên dụng để tra cứu tài liệu hay tận dụng khóa trên không được tối ưu hóa cao cửa hàng giá trị bạn đã có không quan trọng với bên ngoài, nhưng chắc chắn ảnh hưởng đến cấu trúc chi phí của bạn để phục vụ các tài liệu.

Nếu bạn có một ứng dụng web có dữ liệu liên tục, cấu trúc chi phí đó sẽ thay đổi: bạn luôn có chi phí hoạt động để chạy ứng dụng và tích hợp giải mã URL vào nó giúp cho nhiều tính năng dễ thực hiện hơn, giảm chi phí.

Lúc đầu, các URL được ánh xạ trực tiếp tới các đường dẫn tệp trên máy chủ bởi vì nó dễ dàng và dù sao cũng không có cách nào khác để làm điều đó, phải không? Nếu tôi yêu cầu /path/to/index.php, tôi sẽ /path/to/index.phpbắt đầu từ thư mục gốc của trang web (thường không phải của chính máy chủ, trang web nên được giữ trong một thư mục hoặc thư mục con tiếp theo).

Sau một vài năm, chúng tôi bắt đầu tìm hiểu về việc viết lại, đó là phục vụ một nguồn tài nguyên khác với tài nguyên rõ ràng được yêu cầu. /request/path/to/index.phpthực sự có thể phục vụ /response/path/to/index.php.

Một mẹo khác là che giấu index.php. Nếu tôi yêu cầu /index.php?foo=bar&baz=quxmáy chủ có thể trả lời bằng cách ẩn index.phpnhư vậy : /?foo=bar&baz=qux, tất cả trong khi thực sự phục vụ bằng index.phpmọi cách.

Bước tiếp theo, điều quan trọng nhất, là chúng tôi đã học cách chuyển hướng tất cả các URL sang /index.php. Vì vậy, bây giờ, /path/to/some/pageđang âm thầm chuyển hướng đến /index.php?path/to/some/page. Điều này hơi khó, vì thông thường mỗi dấu gạch chéo thể hiện một thư mục con mới, nhưng trong trường hợp này, máy chủ web được cấu hình để gửi đường dẫn dưới dạng tham số, thay vì nhìn vào nó.

Bây giờ chúng ta có điều này, chúng ta cần một cách suy nghĩ hoàn toàn khác về cách tổ chức trang web. Trước đây, nó là một bộ sưu tập lỏng lẻo của các trang khác nhau. Bây giờ, mọi thứ được chuyển qua một trang nhập duy nhất. Điều này làm cho trang web phức tạp hơn nhiều, nhưng cung cấp các cơ hội không có sẵn trước đây, chẳng hạn như xác thực người dùng trên toàn trang web, ứng dụng thống nhất các tiêu đề, chân trang và kiểu, v.v.

Nó có hiệu quả biến hàng trăm hoặc hàng nghìn trang web ứng dụng của bạn (nếu bạn coi mỗi tệp là ứng dụng của riêng mình) thành một ứng dụng duy nhất, phức tạp hơn nhiều nhưng phù hợp hơn nhiều.

Đây là một bước nhảy vọt lớn, vì bạn không còn có thể biết mã nào sẽ được thực thi chỉ bằng cách nhìn vào URL. Bây giờ bạn cần có một sự hiểu biết sâu sắc về cách khung cụ thể của bạn chuyển các đường dẫn URL thành các đường dẫn mã và mặc dù có sự tương đồng giữa các khung, hầu hết đều khác nhau đến mức bạn cần có sự quen thuộc để có thể làm việc với mã.

Tóm lại, đó là một sự phát triển dần dần của khám phá, không phải là một bước nhảy đột ngột, và mỗi nhà phát triển gần như phải trải qua cùng một hành trình khám phá. Đường cong học tập khá dốc, trừ khi bạn có thể nắm bắt các khái niệm trừu tượng thực sự nhanh chóng.

Là một webdev lâu năm, tôi nghĩ rằng sự ra đời của kiểm soát lịch sử không điều hướng ( history.pushState()) vào khoảng thời gian của HTML5 đã khiến điều này trở nên thiết thực. Trước đó, bạn phải tải lại trang để cập nhật thanh URL, trừ khi bạn chỉ cập nhật đoạn ( /path#fragment). Đoạn này là vô hình đối với máy chủ (nó không được định tuyến), vì vậy cách duy nhất để làm mới hoặc đánh dấu trang động là thông qua JavaScript.

Điều này có ý nghĩa chính đối với SEO và khiến google phát triển một lược đồ "hashbang" ít được sử dụng , yêu cầu ánh xạ băm động phía máy chủ đến các URL vật lý. Điều này rất khó sử dụng và không phổ biến giữa các robot, dẫn đến tiên đề (sai): "nhện không thể thu thập nội dung ajax". Nhưng lợi ích của nội dung ajax là hữu hình: thử sử dụng google maps w / o JS chẳng hạn.

Giải pháp là một cách để cập nhật thanh URL với giá trị có thể được nhân đôi trên máy chủ (cho phép đánh dấu trang và làm mới không cần mã hóa), mà KHÔNG tải lại trang. Khi khả năng này đã có sẵn, các nhà phát triển có thể "điều hướng" một trang web bằng cách cập nhật "phần nội dung chính", thanh URL và mẩu bánh mì. Điều này có nghĩa là tất cả các JS + CSS không cần tải lại + phân tích cú pháp, cho phép chuyển từ trang này sang trang nhanh hơn NHIỀU.