Nghĩa của Thương lượng Nội dung là gì? Giải thích các Đại diện HTTP

Nghĩa của Thương lượng Nội dung là gì?

Thương lượng nội dung là quá trình HTTP để chọn một đại diện của một tài nguyên khi có nhiều biến thể có sẵn. Một khách hàng có thể thể hiện sở thích về loại phương tiện, ngôn ngữ, mã hóa nội dung, hoặc các chiều liên quan, và máy chủ chọn một phản hồi phù hợp theo các biến thể và chính sách có sẵn của nó. Tài nguyên vẫn giữ nguyên về mặt khái niệm trong khi đại diện trả về có thể khác nhau.

Định nghĩa hữu ích bao gồm cả cơ chế và ranh giới của nó. Thương lượng Nội dung ảnh hưởng đến một phần cụ thể của một giao dịch, trong khi các trách nhiệm liền kề vẫn thuộc về HTTP, trình duyệt, phương tiện đã chọn, ứng dụng hoặc mô hình dữ liệu của máy chủ. Giữ các lớp đó riêng biệt làm cho báo cáo lỗi có thể tái lập và ngăn chặn việc thay đổi cấu hình bị nhầm lẫn với quyết định kiểm soát truy cập.

Đối với các nhà phát triển API, câu hỏi đầu tiên là ai tạo ra giá trị hoặc hành vi. Câu hỏi tiếp theo là ai diễn giải nó. Câu hỏi cuối cùng là kết quả quan sát nào chứng minh rằng sự diễn giải đã hoạt động. Ba câu trả lời đó biến một thuật ngữ từ điển thành một hợp đồng giao diện có thể kiểm tra được.

Cách HTTP chọn một đại diện

Trong thương lượng chủ động, khách hàng gửi các trường sở thích như Accept, Accept-Language, và Accept-Encoding. Giá trị có thể bao gồm trọng số chất lượng xếp hạng các lựa chọn thay thế. Máy chủ áp dụng thuật toán lựa chọn riêng vì HTTP định nghĩa ngữ pháp sở thích nhưng không quy định một thuật toán xếp hạng toàn cầu nào.

Phản hồi được chọn mang theo siêu dữ liệu đại diện như Content-Type, Content-Language, và Content-Encoding. Vary thông báo cho bộ nhớ đệm các trường yêu cầu đã ảnh hưởng đến việc lựa chọn. Nếu không có sự biến đổi chính xác, một bộ nhớ đệm có thể phục vụ một ngôn ngữ hoặc mã hóa cho một khách hàng đã yêu cầu một ngôn ngữ khác.

Thương lượng phản ứng bắt đầu với một phản hồi phơi bày các lựa chọn thay thế và cho phép tác nhân người dùng chọn. Điều này ít phổ biến hơn đối với các API web thông thường, nhưng có ích về mặt khái niệm: máy chủ có thể từ chối đoán và đưa ra cho khách hàng một bước lựa chọn khác.

Một máy chủ có thể trả về 406 khi không có đại diện có sẵn nào là chấp nhận được, mặc dù nhiều hệ thống chọn một mặc định. Đối với các thân yêu cầu, 415 có thể báo cáo một loại phương tiện không được hỗ trợ. Sở thích phản hồi và hỗ trợ thân yêu cầu là những thương lượng liên quan nhưng diễn ra theo các hướng khác nhau.

Các Trường Đằng Sau Việc Chọn Đại Diện

Các thuật ngữ sau đây tách biệt các thành phần thường bị gộp lại thành một nhãn. Đọc chúng như những giao diện giữa các bên tham gia thay vì như một trang trí trong một bản theo dõi mạng.

Tại sao Thương lượng Nội dung lại Quan trọng trong Việc Thu thập Dữ liệu Web

Thương lượng Nội dung có thể thay đổi những gì các byte đến, cách mà các byte đó được diễn giải, hoặc liệu mã của trình duyệt có thể quan sát kết quả hay không. Một quy trình thu thập nên xác định được tác động đó trước khi thay đổi công cụ. Ghi nhận URL đã yêu cầu, URL cuối cùng, trạng thái phản hồi, loại đại diện, các trường giao thức liên quan, và một dấu hiệu nội dung dự kiến. Bản ghi nhỏ gọn đó phân biệt một trang đúng với một thông điệp truy cập, màn hình đồng ý, mục tiêu chuyển hướng, khung ứng dụng trống, hoặc mã hóa không tương thích.

HTTP trực tiếp là con đường thu thập đơn giản nhất khi dữ liệu cần thiết tồn tại trong một phản hồi do máy chủ mở. Một trình duyệt trở nên liên quan khi nội dung đã được phê duyệt phụ thuộc vào việc thực thi JavaScript, trạng thái được quản lý bởi trình duyệt, điều hướng, hoặc chính sách bảo mật của trình duyệt. Hai con đường này không nên bị buộc phải trông giống nhau: trình duyệt quản lý cookie, nén, chuyển hướng, CORS, và lưu trữ theo các quy tắc của nền tảng, trong khi một khách hàng trực tiếp phơi bày một tập hợp mặc định khác.

Liên tục phiên là quan trọng bất cứ khi nào một phản hồi thiết lập trạng thái cho yêu cầu tiếp theo. Giữ một chuỗi đã ủy quyền bên trong một ngữ cảnh khách hàng giới hạn, bảo tồn địa điểm và nguồn mạng cần thiết, và tránh pha trộn trạng thái từ các công việc không liên quan. Một proxy thay đổi nguồn mạng; nó không tái tạo tiêu đề, giải mã các đại diện, thực thi các kịch bản, hoặc cấp quyền truy cập vào nội dung bị hạn chế.

Phân tích chỉ bắt đầu sau khi xác thực đại diện. Xác nhận máy chủ cuối cùng, danh tính chuẩn nếu có, loại phương tiện, trạng thái giải mã, và dấu hiệu kinh doanh cần thiết trước khi trích xuất các trường. Thứ tự này ngăn cản một bộ phân tích biến một tài liệu lỗi thành các bản ghi trống mà dường như thành công về mặt kỹ thuật.

Các trung gian xứng đáng được chú ý rõ ràng. Một mạng phân phối nội dung có thể chọn một biến thể đã mã hóa, một cổng có thể trả lời OPTIONS, một bộ nhớ cache có thể tái sử dụng một phản hồi đã thương lượng, và một máy chủ ứng dụng có thể thiết lập cookies hoặc các trường ủy quyền.

API Scraping Universal không có tạp chất là liên quan khi một đội cần việc thu thập quản lý nội dung công khai được phép, bao gồm các trang được kết xuất bằng JavaScript. Hợp đồng mua lại vẫn nên xác định mục tiêu, các trường cho phép, đại diện mong đợi, dấu chấp nhận, và điều kiện dừng.

Nơi Thương lượng Giải Quyết Một Vấn Đề Thực Tế

Thương lượng Nội dung có được một vị trí trong kiến trúc khi nó thay đổi hành vi sản phẩm cụ thể, yêu cầu tương thích, hoặc quyết định chẩn đoán. Những trường hợp sử dụng này mô tả công việc trước tiên và tính năng giao thức thứ hai.

Lựa chọn Chủ động, Phản ứng và Dựa trên URL

Thương lượng Nội dung thuộc về một lớp của HTTP và không nên bị nhầm lẫn với các lớp lân cận. Một triển khai hợp lý xác định thành phần nào chọn giá trị, thành phần nào có thể thay đổi nó, và bằng chứng gì chứng minh rằng đại diện cuối cùng là đúng.

Một so sánh chỉ hữu ích nếu nó bảo tồn ranh giới lớp. Hai cơ chế có thể đồng tồn tại trong một yêu cầu, và việc thay thế một không tự động thay thế cái kia. Ghi lại hành vi đã chọn theo các đầu vào, đầu ra quan sát được, trạng thái thất bại, và chủ sở hữu.

Sai lầm trong Thương lượng Nội dung

• Bỏ qua Vary. Bộ nhớ cache cần biết sở thích yêu cầu nào đã thay đổi đại diện đã chọn.
• Xem trọng trọng số chất lượng như một lệnh. Trọng số xếp hạng sở thích của khách hàng, trong khi khả năng và chính sách của máy chủ vẫn xác định kết quả.
• Tải quá User-Agent. Suy luận User-Agent là dễ vỡ và kém rõ ràng hơn các trường thương lượng được thiết kế đặc biệt.
• Trả về Content-Type sai. Khách hàng phân tích biểu diễn đã chọn bằng cách sử dụng siêu dữ liệu phản hồi, vì vậy một loại sai có thể gây ra sự cố trong việc xử lý.
• Đàm phán quá nhiều chiều. Mỗi chiều tăng số khóa bộ nhớ đệm, thử nghiệm và khả năng lựa chọn bất ngờ.
• Ẩn các URL biến thể chuẩn. Các URL khác nhau có thể cải thiện việc liên kết và gỡ lỗi ngay cả khi đàm phán cung cấp một mặc định thuận tiện.

Hầu hết các lỗi trở nên dễ chẩn đoán hơn sau khi loại bỏ những giả định về những gì một thư viện hoặc trình duyệt đã tự động làm. Ghi lại một dấu vết tối thiểu, xóa bí mật, và thay đổi một biến được kiểm soát tại một thời điểm. Mục tiêu là một giải thích ổn định về biểu diễn trả về, không phải một tập hợp các điều chỉnh tiêu đề không liên quan.

Một cuộc Kiểm Toán Lựa Chọn Biểu Diễn

Chuỗi này hoạt động như một đánh giá thiết kế trước khi ra mắt và như một chẩn đoán sản xuất sau khi hành vi thay đổi. Nó giữ bằng chứng giao thức liên kết với kết quả ứng dụng.

1. Liệt kê các biểu diễn thực sự có sẵn cho một tài nguyên và các chiều khác nhau.
2. Gửi các giá trị Accept, Accept-Language và Accept-Encoding đã kiểm soát một lần một.
3. Ghi lại Content-Type, Content-Language, Content-Encoding và Vary cho mỗi kết quả.
4. Kiểm tra một sở thích không chấp nhận được và tài liệu xem máy chủ trả về 406 hay một mặc định.
5. Kiểm tra bộ nhớ đệm chia sẻ với hai khách hàng thể hiện các sở thích khác nhau.
6. Xác minh rằng điều chuyển hướng bảo tồn hợp đồng biến thể dự định và không xóa lựa chọn ngôn ngữ hoặc định dạng.
7. Giữ một URL riêng biệt cho các biến thể mà người đọc hoặc hệ thống cần đánh dấu, lập chỉ mục hoặc so sánh trực tiếp.

Kết thúc đánh giá bằng cách lưu một mẫu chấp nhận nhỏ và một mẫu bị từ chối với cùng các quy tắc xóa bỏ. Các thay đổi trong tương lai có thể được so sánh với danh tính trang đã biết, các trường mong đợi và nội dung đã giải mã thay vì chỉ bộ nhớ hoặc ảnh chụp màn hình.

An Ninh và Tính Có Thể Quan Sát cho Đàm Phán Nội Dung

Đàm phán nội dung tham gia vào một đường yêu cầu có thể đi qua trình duyệt, cổng, bộ nhớ đệm và máy chủ gốc. Mỗi bước nhảy nên chỉ chấp nhận các giá trị mà nó hiểu, bảo tồn các trường phải sống sót, và tránh sao chép thông tin xác thực hoặc dữ liệu cá nhân vào nhật ký. Cú pháp giao thức không phải là sự ủy quyền.

Các hồ sơ hoạt động nên ghi lại URL yêu cầu, URL cuối cùng, trạng thái, loại biểu diễn, tên trường liên quan và một dấu hiệu nội dung được giới hạn. Các thân đầy đủ và giá trị xác thực hiếm khi cần thiết cho chẩn đoán thông thường và có thể tạo ra rủi ro giữ lại không cần thiết.

Hành vi của trình duyệt và hành vi HTTP trực tiếp là các bề mặt kiểm tra khác nhau. CORS, lưu trữ cookie, giải nén tự động, và xử lý chuyển hướng có thể được thực hiện bởi trình duyệt hoặc thư viện trước khi mã ứng dụng nhìn thấy một kết quả. Ghi lại khách hàng và các mặc định của nó khi so sánh các bộ thu.

Các Tiêu Chuẩn Định Nghĩa Đàm Phán Nội Dung

các đặc tả đàm phán nội dung HTTP định nghĩa đàm phán chủ động, bị động, và theo yêu cầu. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng đã chọn và triển khai.

Hướng dẫn đàm phán nội dung của MDN giải thích các trường và mẫu lựa chọn phổ biến. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng đã chọn và triển khai.

đăng ký loại phương tiện IANA liệt kê các loại phương tiện biểu diễn đã được đăng ký. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng đã chọn và triển khai.

các đặc tả đối sánh phạm vi ngôn ngữ định nghĩa việc đối sánh cho các thẻ ngôn ngữ. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi thực hiện vẫn cần được quan sát trong khách hàng đã chọn và triển khai.

Bài Kiểm Tra Thiết Kế Đàm Phán

Sử dụng đàm phán nội dung khi nhiều biểu diễn thực sự chia sẻ một danh tính tài nguyên, giữ các chiều lựa chọn rõ ràng và làm cho sự thay đổi bộ nhớ đệm và siêu dữ liệu phản hồi trở thành một phần của hợp đồng.

Đưa quy tắc đó vào một bài kiểm tra chấp nhận. Nêu rõ ai là người tham gia gửi tín hiệu, ai là người tham gia diễn giải nó, ai là người trung gian có thể thay đổi đường đi, và dấu hiệu nội dung nào chứng minh thành công. Điều này làm cho Đàm Phán Nội Dung trở thành một phần của hệ thống có thể quan sát được thay vì chỉ là một nhãn gắn sau một lỗi.

Tài liệu tham khảo

• Tài liệu API thu thập dữ liệu đa năng không tì vết
• Tổng quan sản phẩm API thu thập dữ liệu đa năng không tì vết
• Hướng dẫn Scrapeless về tiêu đề, cookie, phiên, và xác thực đại diện
• Scrapeless trên GitHub