Một URI được dự định để xác định một tài nguyên .
Tài nguyên đề cập đến những điều thực tế đang được lấy. Trên một trang web, đó thường là một trang . Trong API REST, thông thường nó sẽ là một thực thể - người, hồ sơ, widget, ảnh, v.v.
Các tiêu đề HTTP cho máy chủ biết những điều về máy khách - chúng không mô tả bất cứ điều gì về chính tài nguyên đó hoặc cung cấp bất kỳ trợ giúp nào trong việc định vị tài nguyên đó.
Ví dụ:
Accept-Encoding báo cho máy chủ biết rằng máy khách biết cách chuyển đổi hoặc giải nén nội dung nhất định.Accept-Language nói với máy chủ rằng máy khách đang ở một miền địa phương nhất định và thích nội dung ở miền địa phương đó.Authorization nói với máy chủ rằng máy khách nghĩ rằng nó được phép truy cập vào một tài nguyên được bảo vệ.
Một chủ đề phổ biến với phần lớn các tiêu đề yêu cầu này là máy chủ không bắt buộc phải tôn vinh chúng. Một Accept-Encodingtrong số gzipđó không đảm bảo rằng phản hồi sẽ được nén. Một Accept-Languagetrong số đó ur-PKcó khả năng bị bỏ qua khi truy cập vào một trang web của Hoa Kỳ, trừ khi họ đặc biệt hỗ trợ tiếng Urdu. Và máy chủ có quyền xác minh Authorizationtiêu đề và trả lại 401 hoặc 403, nếu nó không giống như những gì nó thấy.
Không có tiêu đề nào trong số này được dự định thay đổi mạnh mẽ bất cứ điều gì về tài nguyên mà máy chủ cung cấp để đáp ứng. Các Accepttiêu đề là không khác nhau. Nếu một máy khách chỉ định application/xmlvà máy chủ chỉ hỗ trợ application/json, thì máy chủ sẽ gửi lại JSON - không phải XML. Quan trọng hơn, Accepttiêu đề có thể chỉ định nhiều loại, trong trường hợp đó, máy chủ có thể trả lại bất cứ loại nào nó thích (hoặc không có loại nào). Như bạn có thể tưởng tượng, điều này có thể dễ dàng dẫn đến hành vi không xác định cho người dùng, nhưng hãy bỏ qua điều đó ngay bây giờ.
Mục đích của một siêu liên kết là liên kết đến một trang - trang là một loại tài nguyên nhất định. Hoặc, bạn có thể được chứng minh bằng định nghĩa lỏng lẻo về việc liên kết đơn giản với tài nguyên, ngay cả khi tài nguyên đó là một thứ gì đó không phải là một trang (có thể là hình ảnh hoặc tập dữ liệu). Tuy nhiên, điều chắc chắn không có nghĩa là phải làm là liên kết đến một đại diện cụ thể của tài nguyên. Đó là để khách hàng và máy chủ đàm phán, và máy chủ quyết định cuối cùng.
Accept-Languagelà một ví dụ rõ ràng về lý do tại sao nó có thể có vấn đề khi cho phép các siêu liên kết kiểm soát các tiêu đề. Nó không thực sự có ý nghĩa, nếu bạn nghĩ về nó. Mỗi người dùng kiểm soát sở thích ngôn ngữ của mình; nó được cấu hình trong hệ điều hành và / hoặc trình duyệt. Trình duyệt phải luôn gửi cùng một Accept-Language tiêu đề, bất kể trang nào đang được truy cập. Nếu máy chủ hỗ trợ ngôn ngữ đó, thật tuyệt; nếu không, nó sẽ phản hồi với bất kỳ ngôn ngữ nào mà nó cho là gần nhất.
Nếu điều này có thể được thay đổi bởi các siêu liên kết, thì về cơ bản các liên kết trong nước có thể buộc bạn vào phiên bản tiếng Trung của trang web, ngay cả khi trình duyệt và hệ điều hành của bạn không được định cấu hình để hỗ trợ ngôn ngữ đó. Điều đó không có ý nghĩa. Nếu trang web hỗ trợ tiếng Anh và trình duyệt của bạn là tiếng Anh, thì nó sẽ phản hồi bằng tiếng Anh, bất kể siêu liên kết nói gì.
Tương tự, nếu trình duyệt của bạn biết cách hiển thị XML dưới dạng dữ liệu có cấu trúc và có thể tìm XSL để làm cho nó trông đẹp hơn, nhưng thực sự không biết phải làm gì với JSON ngoài việc loại bỏ nó dưới dạng văn bản thuần túy, sau đó buộc chúng phải Nội dung JSON bằng cách liên kết (nếu điều đó là có thể) là một hành vi thù địch mạnh mẽ của người dùng. Trình duyệt phải luôn là người nói: "Tôi biết cách hiển thị X, nhưng không phải là Y, vì vậy tôi thực sự thích nếu bạn cho tôi X".
Tôi có thể hiểu tại sao bạn có thể nghĩ rằng nó hợp lý khi cho phép người dùng trình duyệt ghi đè quyết định này. Nhưng sự thật của vấn đề là bạn đang nghĩ về một vài trường hợp nhỏ như tải xuống báo cáo; 99% thời gian, khi lựa chọn này tồn tại, người dùng không đủ điều kiện hoặc không có đủ thông tin để thực hiện.
Nói cách khác, hãy tưởng tượng cha mẹ hoặc ông bà của bạn sẽ tải xuống một tệp và được yêu cầu chọn văn bản / csv hoặc văn bản / thuần túy. Họ có khả năng biết sự khác biệt? Tôi không biết về bạn, nhưng tôi thường không thể nhận ra sự khác biệt giữa quảng cáo biểu ngữ và thông báo lỗi, vì vậy không có cách nào họ có thể đưa ra lựa chọn này một cách thông minh. Mặt khác, có thể có một tia hy vọng nếu họ được cung cấp các liên kết riêng để tải xuống "sổ làm việc Excel" hoặc "Chỉ văn bản" - mà chúng thực sự là các tài nguyên riêng biệt , không chỉ là đại diện khác nhau của cùng một tài nguyên và các URI sẽ phản ánh điều đó.
Người dùng không thể dựa vào để hiểu rằng hai thứ này thực sự là cùng một tài nguyên, nhưng đại diện khác nhau. Và không thay đổi mọi thứ về cách thức hoạt động của web ngày hôm nay, chúng ta không thể thừa nhận bất cứ điều gì về những gì họ sẽ làm với siêu liên kết đó. Họ có thể nhấp hoặc họ có thể nhấp chuột phải -> "lưu dưới dạng" hoặc họ có thể sao chép và dán nó vào thanh địa chỉ hoặc họ có thể đang sử dụng trình quản lý tải xuống hoặc họ vẫn có thể đang sử dụng IE6 hoặc họ có thể đang sử dụng một số máy tính bảng hoặc thiết bị di động không có thương hiệu với trình duyệt độc quyền ... và trong nhiều trường hợp này, họ sẽ không có được nội dung họ muốn, bởi vì họ sẽ mất một phần của siêu liên kết tuyên bố loại nội dung hoặc trình duyệt của họ sẽ không hỗ trợ nó.
Thông số HTML có thể được thiết kế 40 năm trước để hỗ trợ thuộc tính loại nội dung trong siêu liên kết không? Có thể, mặc dù như tôi đã mô tả trong một số đoạn đầu tiên, có những lý do mạnh mẽ chống lại nó, đặc biệt là trong thời gian băng thông và tài nguyên máy chủ khan hiếm và ý tưởng có thể tải xuống cùng một báo cáo ở nhiều định dạng (hoặc, thẳng thắn , tải xuống bất kỳ báo cáo nào) thực sự đã không xảy ra với bất cứ ai. Nhưng chắc chắn trong thế giới ngày nay, sẽ thật điên rồ khi thử thêm một cái gì đó như thế vào thông số kỹ thuật; nó sẽ phá vỡ hoàn toàn khả năng tương thích ngược và dẫn đến "hành vi không xác định" đáng sợ trong mọi trình duyệt hiện có.