Cách Tìm và Lấy Dữ Liệu APIs Ẩn Với DevTools Trình Duyệt

TL;DR:

• Một API ẩn là một yêu cầu mà trang sử dụng nhưng không quảng cáo như một API phát triển công khai. Nó có thể trả lại JSON, dữ liệu GraphQL, đoạn HTML, hoặc một luồng được tiêu thụ bởi giao diện người dùng.
• DevTools của trình duyệt tiết lộ hợp đồng yêu cầu. Ghi lại hành động của trang, lọc Fetch/XHR, kiểm tra URL, phương thức, truy vấn, tải trọng, phản hồi, người khởi xướng và hành vi phân trang.
• Tái tạo chỉ các yêu cầu công khai hoặc được ủy quyền. Ngừng lại khi yêu cầu phụ thuộc vào đăng nhập, dữ liệu riêng tư, mã thông báo kiểm soát truy cập, hoặc một cách sử dụng bị cấm bởi các điều khoản của trang web.
• Giữ trình duyệt như một lớp khám phá và dự phòng. Một điểm cuối nội bộ có thể thay đổi mà không cần thông báo, và một số yêu cầu cần cookie hoặc trạng thái được thiết lập trong cùng một phiên trình duyệt.
• Xác thực các trường và danh tính trang. Một trạng thái thành công không đủ; kiểm tra sơ đồ mong đợi, vùng miền, con trỏ phân trang, và các hồ sơ công khai cần thiết.

Nhiều trang JavaScript lấy nội dung thực của chúng sau khi tài liệu được tải. Các thẻ đã được kết xuất chỉ là một cách trình bày của một phản hồi có cấu trúc đã được nhìn thấy trong bảng Mạng của trình duyệt.

Việc thu thập dữ liệu từ các API ẩn có nghĩa là quan sát những yêu cầu được khởi xướng từ trình duyệt và, khi dữ liệu là công khai hoặc rõ ràng được ủy quyền, tái tạo hợp đồng yêu cầu nhỏ nhất ổn định. Nó không có nghĩa là phát hiện các điểm cuối riêng tư, vượt qua xác thực, hoặc mở rộng quyền của một trang.

Thế nào là một API ẩn?

Một API ẩn là một giao diện HTTP hoặc WebSocket nội bộ được sử dụng bởi giao diện người dùng của một trang mà không được trình bày như một API công khai hỗ trợ. Điểm cuối có thể không được tài liệu hóa và có thể thay đổi bất cứ khi nào giao diện người dùng thay đổi.

Các hình dạng phản hồi phổ biến bao gồm:

• Các đối tượng hoặc mảng JSON;
• Bao bì phản hồi GraphQL;
• Các đoạn HTML được chèn vào trang;
• Các luồng sự kiện phân cách bằng dòng mới;
• Các định dạng nhị phân cần trình giải mã riêng của trang.

Cụm từ này mô tả khả năng khám phá, không phải quyền truy cập. Một yêu cầu có thể nhìn thấy trong trình duyệt vẫn có thể mang theo trạng thái tài khoản, dữ liệu cá nhân, nội dung có giấy phép, hoặc các hạn chế hợp đồng. Giữ quy trình làm việc trong các bề mặt công khai hoặc được ủy quyền.

Thu thập DOM so với Yêu cầu JSON Nội bộ

Nguồn đúng là nguồn trả về các trường đã được chấp thuận với hợp đồng ổn định nhỏ nhất.

Sử dụng DOM khi việc trình bày của trang là nguồn quyền lực hoặc khi hợp đồng yêu cầu quá mong manh. Sử dụng phản hồi nội bộ khi nó phơi bày các trường công khai cần thiết một cách rõ ràng và quy trình làm việc có thể tôn trọng các ranh giới truy cập tương tự.

Bước 1 — Mở DevTools Trước Hành Động Của Trang

Bảng Mạng chỉ ghi lại các yêu cầu được thực hiện trong khi nó mở. Mở DevTools, chọn Mạng, bật Giữ lại nhật ký khi điều hướng liên quan, và xóa danh sách hiện có.

Tài liệu Tham khảo Mạng DevTools Chrome ghi lại Giữ lại nhật ký, bộ lọc loại yêu cầu, kiểm tra tải trọng, xem trước phản hồi, người khởi xướng, xuất HAR, và Sao chép như fetch hoặc cURL.

Bây giờ thực hiện một hành động để tải dữ liệu:

• gửi một tìm kiếm công khai;
• chuyển đổi một danh mục;
• tải trang kết quả tiếp theo;
• mở rộng một bảng chi tiết công khai;
• cuộn cho đến khi lô tiếp theo xuất hiện.

Một hành động tạo ra một sự khác biệt yêu cầu nhỏ hơn, có thể kiểm toán hơn là tương tác với toàn bộ trang trước.

Bước 2 — Lọc Fetch/XHR và Tìm Phản Hồi Chứa Dữ Liệu

Chọn Fetch/XHR, sau đó kiểm tra các yêu cầu có thời gian đồng bộ với hành động trang. Tìm kiếm nội dung phản hồi cho một giá trị công khai ổn định có thể nhìn thấy trên trang, chẳng hạn như ID mục, tiêu đề chính xác, hoặc mã danh mục.

Kiểm tra các trường này:

Không sao chép mọi tiêu đề của trình duyệt. Bắt đầu từ phương thức, URL, tải trọng, và ngữ cảnh công khai đã được tài liệu hóa. Thêm một tiêu đề chỉ khi một kiểm tra có kiểm soát chứng minh rằng hợp đồng yêu cầu cần nó.

Bước 3 — Quyết định Xem Yêu cầu Có An toàn Để Tái hiện Hay Không

Yêu cầu có thể tái hiện phải nằm trong cùng một ranh giới ủy quyền như trang.

Tiến hành khi:

• phản hồi chứa dữ liệu công khai mà người dùng có thể truy cập mà không cần tài khoản;
• yêu cầu là một phần của tích hợp hoặc thử nghiệm được ủy quyền rõ ràng;
• khối lượng dự kiến là hợp lý;
• các trường là cần thiết cho bộ dữ liệu đã nêu.

Dừng lại khi:

• phản hồi tiết lộ dữ liệu riêng tư hoặc dữ liệu có phạm vi tài khoản;
• việc tái hiện sẽ vượt qua ranh giới đăng nhập, tường phí, hoặc kiểm soát truy cập;
• yêu cầu phụ thuộc vào một bí mật không phải của bạn để sử dụng;
• các điều khoản của trang web hoặc sự chấp thuận của dự án không cho phép hoạt động đó.

Hướng dẫn xuất Chrome HAR lưu ý rằng các bản xuất đã được làm sạch bỏ qua các tiêu đề nhạy cảm như Cookie, Set-Cookie và Authorization. Sử dụng các bản ghi đã được làm sạch cho tài liệu trừ khi nhiệm vụ gỡ lỗi đã được phê duyệt yêu cầu đặc biệt các giá trị được bảo vệ.

Bước 4 — Sao chép Yêu cầu, Sau đó Giảm Thiểu Nó

DevTools có thể sao chép một yêu cầu dưới dạng cURL hoặc như một cuộc gọi Node.js fetch. Xem đầu ra đó như một bức tranh chẩn đoán, không phải mã sản xuất.

Gỡ bỏ theo thứ tự này:

1. các tiêu đề theo dõi và được tạo bởi trình duyệt;
2. các cookie không liên quan đến đại diện công khai;
3. các giá trị tương quan một lần;
4. các tham số không làm thay đổi kết quả yêu cầu;
5. các tiêu đề đàm phán nội dung thừa.

Sau mỗi thay đổi, xác thực lược đồ phản hồi và các bản ghi cần thiết. Mục tiêu là một hợp đồng yêu cầu tối thiểu có thể được giải thích từng trường một.

API Fetch của trình duyệt coi cookies và tiêu đề xác thực là chứng nhận. Hướng dẫn API Fetch MDN giải thích cách xử lý chứng nhận tương tác với các yêu cầu xuyên nguồn. Không mang theo chứng nhận vào một kịch bản độc lập trừ khi công việc được ủy quyền rõ ràng và mô hình lưu trữ và truy cập đã được xem xét.

Bước 5 — Ánh xạ Phản hồi Vào Một Lược đồ Ổn định

Phản hồi nội bộ thường tiết lộ nhiều trường hơn nhu cầu của bộ dữ liệu. Định nghĩa một hợp đồng đầu ra hẹp.

{
  "source_url": "https://example.com/public-search?q=notebook",
  "query": "notebook",
  "page": {
    "cursor": "next-public-cursor",
    "has_more": true
  },
  "items": [
    {
      "id": "item-123",
      "title": "Illustrative public result",
      "url": "https://example.com/public/items/item-123",
      "price": null
    }
  ]
}

Lược đồ ở trên là một mẫu minh họa. Giữ các trường có thể null là có thể null, giữ URL nguồn và giữ một định danh ổn định khi phản hồi cung cấp một cái.

Bắt đầu một phiên Trình duyệt Gạch bỏ Scraping miễn phí khi việc khám phá yêu cầu JavaScript và trạng thái trình duyệt.

Bước 6 — Hiểu Phân Trang Trước Khi Mở Rộng

Phân trang thường xuất hiện ở một trong bốn vị trí:

• một số page trong truy vấn;
• một offset cộng với một giới hạn cố định;
• một con trỏ mờ trong phản hồi;
• một biến GraphQL trong thân yêu cầu.

Kích hoạt chính xác một hành động trang tiếp theo và so sánh hai yêu cầu. Ghi lại giá trị nào đã thay đổi và trường phản hồi nào cung cấp giá trị tiếp theo. Không phát minh hoặc giải mã các con trỏ mờ.

Sử dụng quy tắc dừng liên kết với hợp đồng: has_more trở thành false, con trỏ tiếp theo không có, mảng kết quả trống, hoặc số lượng trang tối đa đã được phê duyệt đã đạt. Loại bỏ trùng lặp dựa trên một ID công khai ổn định thay vì văn bản tiêu đề.

Bước 7 — Giữ Trạng thái Phiên Khi Yêu cầu Cần Nó

Một số yêu cầu nội bộ chỉ hoạt động sau khi trang thiết lập cookies, sự đồng ý, ngôn ngữ, hoặc một trạng thái được cho phép khác. Trong trường hợp đó, giữ lại việc khám phá và trích xuất trong một phiên trình duyệt được giới hạn.

Trình duyệt Gạch bỏ Scraping chạy JavaScript trong một trình duyệt đám mây và giữ trạng thái phiên qua điều hướng được phê duyệt. Sử dụng nó để quan sát yêu cầu và trích xuất phản hồi từ cùng một ngữ cảnh thay vì xuất trạng thái mờ vào một khách hàng không liên quan.

Tài liệu về Trình duyệt Gạch bỏ Scraping ghi lại thời gian sống của phiên giới hạn và các tham số định tuyến địa lý. Giữ địa lý, ngôn ngữ, cookies và thứ tự trang cố định trong khi xác thực yêu cầu.

Khôi phục Trình duyệt: Khi API Nội bộ Là Nguồn Không Chính xác

Trình duyệt vẫn là phương án khôi phục an toàn khi điểm cuối nội bộ không ổn định, có phạm vi tài khoản, liên kết chặt chẽ với trạng thái tạm thời, hoặc thiếu các trường phụ thuộc vào trình bày.

Chọn trích xuất DOM đã được kết xuất khi:

• lược đồ phản hồi thay đổi thường xuyên hơn các yếu tố trang ngữ nghĩa;
• một trường công khai chỉ được tính toán sau khi kết xuất phía khách hàng;
• mô hình ủy quyền của điểm cuối không rõ ràng;
• việc phát lại yêu cầu sẽ yêu cầu sao chép các chứng nhận nhạy cảm;
• đại diện trực quan của trang là bộ dữ liệu chính thức.
  Hướng dẫn rendering JavaScript giải thích sự khác biệt giữa HTML ban đầu, nội dung do khách hàng render và các yêu cầu không đồng bộ.

Khắc phục sự cố Scraping API ẩn

Thay đổi một biến tại một thời điểm và lưu lại một ví dụ đã được dọn dẹp về hình dạng phản hồi được chấp nhận. Nếu yêu cầu vượt qua ranh giới truy cập, hãy dừng lại thay vì điều chỉnh khách hàng.

Kết luận: Xem hợp đồng yêu cầu như một phụ thuộc

Scraping các API ẩn có thể thay thế phân tích DOM dễ vỡ bằng dữ liệu công cộng có cấu trúc, nhưng điểm cuối là một phụ thuộc nội bộ chứ không phải là một hợp đồng công cộng được hỗ trợ. Khám phá nó thông qua một hành động trang, giảm yêu cầu đã sao chép, chỉ ánh xạ các trường cần thiết và ghi lại phân trang và trạng thái.

Giữ một dự phòng trình duyệt cho các thay đổi sơ đồ và các luồng phụ thuộc phiên. Kiểm tra lại quyền hạn bất cứ khi nào trang, điểm cuối, hoặc phạm vi tập dữ liệu thay đổi.

Sẵn sàng để xây dựng một quy trình làm việc trích xuất nhận biết trình duyệt?

Tham gia cộng đồng Scrapeless để thảo luận về khám phá dữ liệu công cộng và thiết kế sơ đồ: Discord · Telegram.

Xem xét giá cả Scrapeless, sau đó đăng ký tại app.scrapeless.com để nhận runtime Scraping Browser miễn phí.

Câu hỏi thường gặp

Q: Việc scraping một API ẩn có hợp pháp không?

Việc scraping một yêu cầu nội bộ có thể hợp pháp khi nó truy cập dữ liệu công cộng hoặc được ủy quyền, nhưng luật pháp, hợp đồng và sự thật khác nhau, vì vậy hãy xem xét các điều khoản của trang web và xin tư vấn pháp lý cho dự án.

Q: API ẩn có giống như API công cộng không?

Một API ẩn được sử dụng nội bộ bởi một frontend và không có cam kết về tài liệu, độ ổn định, hoặc quyền truy cập của bên thứ ba, trong khi một API công cộng được công khai một cách có chủ đích dưới một hợp đồng được hỗ trợ.

Q: Có cần một proxy để kiểm tra các API ẩn không?

Một proxy không cần thiết cho việc kiểm tra DevTools cục bộ nhưng có thể cần thiết cho một tập dữ liệu cụ thể đã được phê duyệt hoặc quy trình thu thập tương xứng.

Q: Bạn nên làm gì khi một yêu cầu nội bộ trả về một trang từ chối truy cập?

Dừng lại và kiểm tra đại diện đã trả về, ranh giới quyền hạn, và phạm vi dự án; không xem một tiêu đề hay token khác nhằm cho phép.

Q: Bạn xử lý các thay đổi DOM hoặc sơ đồ như thế nào?

Chạy lại một hành động trang đã biết, so sánh hợp đồng yêu cầu và phản hồi, cập nhật ánh xạ nullable, và giữ một dự phòng DOM đã render cho các trường mà phản hồi nội bộ không còn cung cấp.

Q: Một trình trích xuất API ẩn nên sử dụng mức độ đồng thời bao nhiêu?

Giữ mức độ đồng thời ở ba hoặc ít hơn công nhân cho mỗi máy chủ cho đến khi các quy tắc đã công bố của trang web, quyền hạn và độ ổn định quan sát được hỗ trợ mức cao hơn.

Q: Quy trình làm việc này có thể chạy mà không có tác nhân AI không?

Có, khám phá DevTools, tái tạo yêu cầu đã dọn dẹp, xác thực sơ đồ, và dự phòng trình duyệt là các bước kỹ thuật có tính toán không yêu cầu một tác nhân AI.