httpx là gì?

Proxy Scrapeless chuyển hướng các yêu cầu HTTP qua cơ sở hạ tầng proxy cho việc thu thập dữ liệu web và các quy trình thu thập dữ liệu khác.

HTTPX là một khách hàng HTTP Python với các giao diện đồng bộ và bất đồng bộ để yêu cầu các trang web và API. Bạn cung cấp cho khách hàng một phương thức, URL và tùy chọn yêu cầu; nó trả về một phản hồi bao gồm trạng thái, tiêu đề, và nội dung. Trong một dòng thu thập dữ liệu, HTTPX lấy tài liệu mà một trình phân tích sau đó chuyển đổi thành các bản ghi.

Sự khác biệt rất quan trọng khi một trang trông như hoàn chỉnh trong trình duyệt nhưng tập lệnh của bạn nhận được một tài liệu hầu như trống rỗng. HTTPX có thể tải xuống phản hồi của máy chủ, nhưng việc tải xuống HTML không thực thi JavaScript được tham chiếu bởi HTML đó. Trước khi chọn cài đặt đồng thời hoặc bộ chọn, hãy thiết lập đại diện nào chứa thông tin bạn cần.

HTTPX xử lý cái gì?

HTTPX xử lý giao tiếp HTTP, bao gồm xây dựng yêu cầu, giải mã phản hồi, tùy chọn xác thực, truyền phát và kết nối tái sử dụng. Các giao diện khách hàng đồng bộ và bất đồng bộ cho phép một dự án giữ một từ vựng yêu cầu tương tự qua các mô hình thực thi khác nhau. Tên gói Python là chữ thường httpx; tên dự án là HTTPX.

Một khách hàng HTTP nằm dưới các quy tắc trích xuất. Nó có thể yêu cầu một danh sách sản phẩm HTML hoặc một điểm cuối danh mục JSON. Đối với HTML, một thành phần khác chọn các phần tử và đọc các trường. Đối với JSON, ứng dụng xác thực cấu trúc đã được giải mã. Không có việc giải mã thành công hoặc trạng thái HTTP thành công nào thiết lập rằng các bản ghi đã được trả về là hoàn chỉnh, liên quan, hoặc hiện tại.

HTTPX cũng khác với một trình thu thập. Thư viện không quyết định liên kết nào được phát hiện thuộc về bộ sưu tập của bạn, duy trì các định danh doanh nghiệp của bạn, hoặc chọn khi nào một nhiệm vụ đã thăm đủ trang. Những trách nhiệm đó vẫn thuộc về ứng dụng của bạn hoặc một khung thu thập tách biệt. Giữ cho ranh giới đó rõ ràng làm cho việc thay đổi dễ dàng hơn để chẩn đoán.

Cách một yêu cầu trở thành một phản hồi

Một yêu cầu HTTPX trở thành một phản hồi thông qua việc thu nhận kết nối, truyền tải, và đọc phản hồi. Khách hàng chuẩn bị URL và tiêu đề, lấy một kết nối phù hợp, gửi yêu cầu, và phơi bày đại diện đã được trả về. HTTPS thêm bảo mật truyền tải; nó không xác định liệu tài liệu có chứa dữ liệu doanh nghiệp dự kiến hay không.

Đối với một nhà thu thập danh mục, chuỗi hữu ích là kiểm tra trạng thái, xác nhận địa chỉ cuối, kiểm tra loại nội dung, và sau đó xác thực tài liệu. Một chuyển hướng đến trang chính có thể trả về HTML dễ đọc trong khi mất danh mục gốc. Một phản hồi JSON có thể chứa một đối tượng lỗi thay vì một danh sách bản ghi. Đây là những kết quả khác nhau và nên giữ được sự phân biệt.

Các tiêu chuẩn ngữ nghĩa HTTP định nghĩa các phương thức, mã trạng thái, và siêu dữ liệu đại diện. Ứng dụng của bạn thêm lớp ý nghĩa tiếp theo: các trạng thái nào là có thể chấp nhận cho hoạt động này, các trường nào xác định một kết quả hợp lệ, và liệu một tập hợp trống có hợp lý cho nguồn này hay không.

Tại sao tái sử dụng một khách hàng HTTPX?

Một khách hàng HTTPX tái sử dụng tạo nhóm kết nối và chia sẻ cấu hình qua các yêu cầu liên quan. Vòng đời khách hàng HTTPX hỗ trợ cookie cố định và tái sử dụng kết nối, trong khi các cuộc gọi ở cấp cao lặp lại không tái sử dụng một nhóm khách hàng chung. Sự khác biệt này trở nên quan trọng khi một nhiệm vụ thực hiện nhiều yêu cầu tới cùng một dịch vụ.

Tạo khách hàng tại phạm vi công việc mà nó sở hữu. Một lô ngắn có thể sở hữu một khách hàng trong suốt tuổi thọ của nó; một dịch vụ có thể sở hữu một khách hàng liên quan đến sự khởi động và tắt máy của ứng dụng. Đóng khách hàng khi phạm vi đó kết thúc để các kết nối của nó không sống lâu hơn công việc. Việc tạo một khách hàng mới trong mỗi thao tác mục bỏ qua nhiều lợi ích.

Cấu hình chia sẻ cũng xứng đáng có một ranh giới. Một khách hàng với tiêu đề xác thực cho một dịch vụ không nên trở thành một tải xuống chung cho các máy chủ tùy ý. Tách biệt các khách hàng khi thông tin đăng nhập, cookie, tuyến đường proxy, hoặc các chính sách yêu cầu khác phải được giữ tách biệt. Tái sử dụng kết nối chỉ hữu ích khi tái sử dụng duy trì ngữ cảnh yêu cầu dự định.

HTTPX đồng bộ hay bất đồng bộ?

HTTPX đồng bộ phù hợp với công việc tuần tự, trong khi HTTPX bất đồng bộ phù hợp với các ứng dụng cần chồng chéo các khoảng chờ mạng độc lập. Khách hàng đồng bộ chặn luồng gọi của nó cho đến khi một hoạt động hoàn thành. AsyncClient phơi bày các hoạt động có thể chờ để một vòng lặp sự kiện tương thích có thể chạy các nhiệm vụ sẵn sàng khác trong khi hoạt động mạng đang chờ.

Chờ từng yêu cầu bên trong một vòng lặp tuần tự vẫn xử lý những yêu cầu đó lần lượt. Tính đồng thời yêu cầu lập lịch các hoạt động độc lập và lập lịch yêu cầu một giới hạn có chủ đích. Một nhóm kết nối giới hạn số kết nối; một hàng đợi ứng dụng giới hạn công việc đang chờ. Không cái nào nên được coi là sự thay thế cho một chính sách yêu cầu theo nguồn cụ thể.

Thời gian chờ, Chuyển hướng và Lựa chọn Giao thức HTTP

HTTPX cung cấp các điều khiển vận chuyển cần được cấu hình xung quanh hoạt động mà bạn dự định thực hiện. Nó thời gian chờ kết nối, đọc, ghi và nhóm mô tả các giai đoạn chờ khác nhau. Thời gian chờ đọc liên quan đến việc chờ dữ liệu phản hồi; thời gian chờ nhóm liên quan đến việc chờ một kết nối khả dụng. Những tín hiệu này chỉ ra những nơi khác nhau trong hệ thống của bạn.

Ghi lại danh mục thất bại với URL nguồn và tên hoạt động. Nếu ứng dụng đang chờ nguồn tài nguyên của chính nó đã cạn kiệt, việc thay đổi một bộ chọn HTML không thể giúp ích. Nếu tài liệu mong đợi đã di chuyển, chính sách chuyển hướng và địa chỉ cuối cùng là quan trọng. HTTPX không tự động theo dõi chuyển hướng, vì vậy hãy quyết định một cách rõ ràng liệu việc theo dõi chúng có phù hợp với bộ sưu tập hay không.

Hỗ trợ HTTP/2 là tùy chọn và phải được kích hoạt với các phụ thuộc cần thiết có sẵn. Việc kích hoạt nó không ép buộc một máy chủ phải sử dụng nó: việc thương lượng giao thức vẫn phụ thuộc vào điểm cuối. Kiểm tra giao thức phản hồi khi chi tiết này quan trọng. Tránh đối xử với một giao thức mới hơn như một cải tiến tốc độ phổ quát; độ trễ nguồn, kích thước tải và xử lý ứng dụng có thể thống trị kết quả.

Một Quy trình Công việc Danh mục Giúp Duy Trì Chất Lượng Dữ Liệu

Một quy trình công việc danh mục HTTPX hữu ích xác thực đại diện trước khi trích xuất các trường sản phẩm. Hãy xem xét một bộ sưu tập minh họa của các trang danh mục công khai nơi mỗi thẻ nên chứa một định danh sản phẩm, tiêu đề và liên kết chi tiết. Định nghĩa những yêu cầu đó trước khi thực hiện trình tải xuống để một trang có thể đọc được nhưng không liên quan không thể trở thành một thành công rỗng một cách im lặng.

1. Giữ danh sách URL danh mục đã được phê duyệt và một điều kiện dừng rõ ràng cho phân trang.
2. Lấy từng trang với ngữ cảnh khách hàng tương ứng với máy chủ và phiên của nó.
3. Kiểm tra danh mục phản hồi, URL cuối cùng và các dấu hiệu tài liệu mong đợi.
4. Chuyển HTML đã chấp nhận vào một trình phân tích và trích xuất các trường trong mỗi container sản phẩm.
5. Lưu các bản ghi đã xác thực với địa chỉ nguồn và ngữ cảnh thu thập của chúng.

Nếu một mức giá không có, hãy bảo tồn sự vắng mặt đó thay vì biến nó thành số không. Nếu một tiêu đề xuất hiện hai lần vì bố cục chứa cả thẻ máy tính để bàn và di động, hãy loại bỏ bản sao theo định danh sản phẩm thay vì theo văn bản tiêu đề. Đây là những quyết định trích xuất. HTTPX có thể cung cấp tài liệu một cách chính xác trong khi mô hình bản ghi vẫn cần sự chú ý.

Tách biệt các quan sát vận chuyển khỏi các quan sát trình phân tích trong nhật ký của bạn. Trạng thái phản hồi và thời gian giải thích việc thu thập. Các container phù hợp, các trường cần thiết bị thiếu và các bản ghi bị từ chối giải thích việc trích xuất. Việc tách biệt đó cho phép bạn thay đổi cấu hình HTTP mà không cần viết lại các quy tắc trường, hoặc cập nhật một bộ chọn mà không làm rối một khách hàng khác vẫn khỏe mạnh.

Nơi Các Proxy không Có Rác Thích Hợp

Các Proxy không Có Rác cung cấp một lớp định tuyến cho các yêu cầu của HTTPX khi một bộ sưu tập cần một vị trí proxy hoặc lộ trình phiên thích hợp. Các giải pháp proxy không có rác bao gồm các loại proxy khác nhau; hãy chọn loại dựa vào nguồn và quy trình làm việc thay vì giả định rằng mọi yêu cầu đều cần cùng một lộ trình.

Giới thiệu về Các Proxy không Có Rác giải thích các gia đình sản phẩm có sẵn, và các hướng dẫn cấu hình proxy HTTPX cung cấp ngữ cảnh bổ sung. Lấy chi tiết điểm cuối hiện tại từ bảng điều khiển và giữ thông tin xác thực bên ngoài các tệp nguồn đã lưu và nhật ký yêu cầu. Thông tin xác thực proxy và một khóa API ứng dụng không phải là các khái niệm có thể hoán đổi cho nhau.

Một proxy thay đổi cách lưu lượng truy cập đến một đích. Nó không thực thi các tập lệnh trang hoặc sửa chữa các bản ghi bị thiếu trong phản hồi. Bảo tồn việc xác minh TLS thông thường và đánh giá kết quả thu thập đầy đủ sau khi đã cấu hình định tuyến. Sử dụng giá cả không có rác để đánh giá các chi phí dịch vụ liên quan thay vì giả định rằng việc kết nối ít hơn với khách hàng có nghĩa là giảm chi phí thu thập tổng thể.

Kết luận

HTTPX là một lựa chọn tốt khi Python cần một khách hàng HTTP với các kết nối có thể tái sử dụng và một lựa chọn thực thi đồng bộ hoặc không đồng bộ. Bắt đầu với hợp đồng phản hồi hợp lệ, căn cứ khách hàng vào công việc, và giới thiệu độ đồng thời có giới hạn chỉ ở những nơi mà các chờ đợi mạng độc lập biện minh cho điều đó. Giữ định tuyến, phân tích và lên lịch thu thập rõ ràng để mỗi thành phần có một nhiệm vụ rõ ràng.