API hoạt động như thế nào?

API Scraping không có rác cho phép các ứng dụng yêu cầu dữ liệu có cấu trúc từ các nguồn web được hỗ trợ thông qua các hoạt động API đã được tài liệu hóa.

Một API là một giao diện đã thỏa thuận cho phép một phần mềm yêu cầu một phần mềm khác thực hiện một hoạt động hoặc trả về thông tin. Người gọi không cần phải biết mọi chi tiết cài đặt bên trong. Họ cần phải biết tên hoạt động, đầu vào được chấp nhận, quy tắc ủy quyền và hình dạng của kết quả. Trên web, những thuật ngữ đó thường được thể hiện thông qua một yêu cầu HTTP và phản hồi.

Hãy tưởng tượng một ứng dụng cần thông tin sản phẩm. Nó chọn một hoạt động đã được tài liệu hóa, gửi đầu vào và thông tin xác thực cần thiết, và nhận kết quả hoặc lỗi. Bài học quan trọng là một cuộc gọi API là một hợp đồng giữa các hệ thống, không phải là một đảm bảo rằng một kết quả kinh doanh cụ thể đã xảy ra. Phản hồi phải được diễn giải và kiểm tra.

Các phần của một yêu cầu API Web

Một yêu cầu API web xác định một điểm đến và một hành động. URL chỉ đến một tài nguyên hoặc hoạt động dịch vụ. Phương thức HTTP truyền đạt loại hành động dự kiến. Các tiêu đề cung cấp siêu dữ liệu như thông tin xác thực ủy quyền hoặc loại phương tiện, trong khi một nội dung có thể chứa đầu vào có cấu trúc. Đặc tả ngữ nghĩa HTTP định nghĩa phương thức và từ vựng trạng thái chung mà nhiều API sử dụng.

Một người gọi nên xây dựng mỗi phần từ hợp đồng nhà cung cấp. Một yêu cầu đến máy chủ chính xác với đường dẫn sai có thể đến một hoạt động khác. Một nội dung JSON hợp lệ với tên trường sai có thể bị thất bại khi xác thực. Một khóa được sao chép vào một URL có thể bị rò rỉ qua nhật ký hoặc lịch sử trình duyệt khi dịch vụ mong đợi một tiêu đề. Hãy coi hình dạng yêu cầu đã được tài liệu hóa như một tổng thể thay vì thu thập các trường có thể có từ các ví dụ không liên quan.

HTTP chỉ là một phương tiện vận chuyển API. Một trình duyệt phơi bày các API cục bộ cho các script, và các dịch vụ khác sử dụng luồng sự kiện hoặc gọi thủ tục từ xa. Mô hình yêu cầu-phản hồi vẫn là một điểm khởi đầu hữu ích cho các dịch vụ web vì nó làm rõ ràng ranh giới: một bên gửi một tin nhắn, và bên kia quyết định cách xử lý nó.

Chuyện gì xảy ra sau khi yêu cầu đến

Máy chủ nhận yêu cầu, kiểm tra rằng nó được trình bày đúng cách, và quyết định liệu người gọi có được phép thực hiện hoạt động hay không. Nó có thể xác thực đầu vào trước khi đọc dữ liệu hoặc bắt đầu công việc. Thứ tự và kiểm tra cụ thể thuộc về cài đặt dịch vụ; khách hàng thấy hiệu ứng của chúng thông qua phản hồi đã được tài liệu hóa. tổng quan về khách hàng-máy chủ minh họa chu kỳ yêu cầu, xử lý máy chủ và phản hồi.

Một số hoạt động kết thúc trong yêu cầu ban đầu. Những hoạt động khác chấp nhận một nhiệm vụ và phơi bày một cách riêng để kiểm tra tiến trình hoặc kết quả cuối cùng. Một khách hàng không được suy ra việc hoàn thành chỉ vì việc nộp đơn trả về mã thành công. Đọc tài liệu hoạt động để biết xem phản hồi có chứa dữ liệu cuối cùng, một định danh nhiệm vụ, hay một xác nhận rằng quá trình đã bắt đầu.

Máy chủ cũng có thể gọi các cơ sở dữ liệu nội bộ hoặc các dịch vụ khác. Những chi tiết đó có thể thay đổi trong khi API công khai vẫn ổn định. Đó là lý do tại sao một khách hàng tốt phụ thuộc vào hợp đồng bên ngoài hơn là hành vi ngẫu nhiên được quan sát một lần. Nếu nhà cung cấp tài liệu một trường là tùy chọn, hãy xử lý sự vắng mặt của nó ngay cả khi mọi phản hồi mẫu đều chứa nó.

Cách phản hồi truyền đạt kết quả

Một phản hồi HTTP bao gồm một trạng thái, tiêu đề và thường là một nội dung. Một trạng thái thành công có thể đi kèm với dữ liệu trả về, một kết quả trống, hoặc xác nhận rằng một hoạt động đã được chấp nhận. Một trạng thái lỗi có thể chỉ ra đầu vào không hợp lệ, thiếu ủy quyền, một tài nguyên không tồn tại, hoặc một vấn đề của máy chủ. Cùng một gia đình trạng thái có thể chứa các chi tiết kinh doanh khác nhau, vì vậy hãy đọc nội dung phản hồi khi API xác định nó.

Đối với các phản hồi có cấu trúc, loại phương tiện là quan trọng. Một khách hàng mong đợi JSON nên trước tiên kiểm tra xem nó đã đến đúng điểm cuối và nhận được loại nội dung mong đợi. Một trang lỗi HTML không phải là một đối tượng JSON với các trường bị thiếu. Phân tích mà không có những kiểm tra này thường che giấu sự thất bại thực sự phía sau một ngoại lệ cú pháp thứ cấp.

Hướng dẫn Fetch API cho thấy cách mã trình duyệt thực hiện các yêu cầu HTTP và kiểm tra các phản hồi. Một lời hứa mạng được giải quyết không có nghĩa là dịch vụ đã chấp nhận hoạt động kinh doanh. Logic của khách hàng phải phân biệt thành công vận chuyển, trạng thái HTTP và xác thực ở mức ứng dụng.

Xác thực, Ủy quyền và Phạm vi

Xác thực xác định người gọi nào đã cung cấp thông tin xác thực. Ủy quyền quyết định những hành động nào mà người gọi đó có thể thực hiện. Một khóa API thường xác định một tài khoản hoặc ứng dụng, trong khi một mã thông báo có phạm vi người dùng có thể đại diện cho quyền truy cập ủy quyền. Dịch vụ quyết định cách nó sử dụng mỗi thông tin xác thực. Một khách hàng nên gửi bí mật chỉ bằng phương pháp mà nhà cung cấp tài liệu và giữ chúng ra ngoài mã phía trước công khai khi họ cấp quyền truy cập ưu tiên.

Thông tin xác thực là một phần của yêu cầu, không phải là sự thay thế cho xác thực đầu vào. Một khóa hợp lệ không làm cho một hoạt động không được hỗ trợ trở nên hợp lệ. Cũng không có phản hồi 200 chứng minh rằng người gọi nhận được bộ dữ liệu mong đợi. Kiểm tra phạm vi, mục tiêu và kết quả yêu cầu cùng nhau. Khi quyền truy cập bị từ chối, hãy kiểm tra lỗi đã được tài liệu hóa và cấu hình khóa trước khi thay đổi các tham số không liên quan.

Scrapeless giải thích cách xử lý khóa trong hướng dẫn khóa API.Thông tin chi tiết về tiêu đề và hoạt động cụ thể của nhà cung cấp thuộc về tài liệu sản phẩm hiện tại. Sử dụng một kho bí mật phía máy chủ hoặc biến môi trường được kiểm soát trong một ứng dụng thực tế; một ví dụ công khai không nên chứa thông tin xác thực cá nhân hợp lệ.

Một ví dụ API Scraping cụ thể

Giới thiệu API Scraping không có rác miêu tả một yêu cầu chọn một trình thu thập dữ liệu với tham số diễn viên. Người gọi cung cấp đầu vào cụ thể cho diễn viên, và dịch vụ trả về dữ liệu có cấu trúc cho các nguồn được hỗ trợ. Đây là một minh họa hữu ích về sự phân tách API: khách hàng xác định hoạt động và đầu vào mong muốn, trong khi dịch vụ xử lý nội bộ việc thu thập và phân tích dữ liệu.

Một ứng dụng vẫn nên chọn diễn viên đúng, xác thực các tham số mục tiêu, và ánh xạ các trường đã trả về. Một kết quả tìm kiếm và một kết quả sản phẩm có thể đều là JSON, nhưng ý nghĩa và hình dạng kinh doanh của chúng khác nhau. Một trình phân tích JSON tổng quát chỉ tạo ra giá trị trong bộ nhớ; mã ứng dụng phải quyết định trường nào trở thành bản ghi và cách xử lý các giá trị bị thiếu hoặc không mong đợi.

Cái tổng quan về sản phẩm API thu thập dữ liệu miêu tả đầu ra có cấu trúc cho các trang web được hỗ trợ. Hướng dẫn liên quan đến diễn viên giải thích rằng điểm cuối và hình dạng kết quả phụ thuộc vào gia đình diễn viên. Bắt đầu với một diễn viên đã được tài liệu hóa và một điều kiện chấp nhận hẹp trước khi tích hợp nhiều loại kết quả vào một quy trình.

Cách Đánh Giá một API Trước Khi Xây Dựng Trên Nó

Bắt đầu với hoạt động bạn cần, chứ không phải tên sản phẩm. Xác định điểm cuối, các trường yêu cầu, phương thức xác thực, sơ đồ phản hồi, đại diện lỗi, và bất kỳ vòng đời bất đồng bộ nào. Kiểm tra tài liệu của nhà cung cấp và một phản hồi đại diện. Nếu ví dụ sử dụng một tuyến đường cũ hơn hoặc tên sản phẩm khác, hãy xác minh trang hiện tại thay vì giả định rằng chuyển hướng bảo vệ hoạt động ban đầu.

Xác định một bài kiểm tra chấp nhận nhỏ bằng các thuật ngữ kinh doanh: kết quả nên chứa một bản ghi cho mục tiêu yêu cầu với các trường mà ứng dụng của bạn cần. Ghi lại trạng thái và hình dạng phản hồi, sau đó so sánh những thực tế đó với tài liệu. Nếu phản hồi không đáp ứng điều kiện, sự tích hợp là chưa hoàn thành ngay cả khi cuộc gọi HTTP thành công.

Cuối cùng, lập kế hoạch cho sự thay đổi tại ranh giới hợp đồng. Một trường được đánh dấu là tùy chọn có thể biến mất. Một trường mới được thêm vào thường không gây hại. Một ý nghĩa thay đổi cho một trường hiện có thì nghiêm trọng hơn nhiều. Cách ly logic ánh xạ để một thay đổi cụ thể từ nhà cung cấp không thay đổi âm thầm mọi người tiêu dùng phía dưới. Điều này giữ cho API còn hữu ích như một giao diện giữa các hệ thống phát triển độc lập.

Kết luận

Một API web hoạt động bằng cách trao đổi các yêu cầu và phản hồi được tài liệu hóa qua một ranh giới phần mềm. Việc sử dụng đáng tin cậy yêu cầu nhiều hơn là gửi một URL: khách hàng phải cung cấp đầu vào và xác thực đúng, giải thích trạng thái và sơ đồ phản hồi, và xác minh kết quả kinh doanh dự định.