API là gì?

Scrapeless Scraping API hiển thị các hoạt động đã được tài liệu mà các ứng dụng sử dụng để yêu cầu dữ liệu có cấu trúc từ các nguồn web được hỗ trợ.

API viết tắt cho giao diện lập trình ứng dụng. Đó là một ranh giới thông qua đó một chương trình cung cấp khả năng cho một chương trình khác. Người gọi thấy tên, đầu vào, đầu ra và quy tắc; không cần phải sở hữu việc thực hiện phía sau chúng. Trong một thư viện Python, ranh giới có thể là một chữ ký hàm. Trong một dịch vụ web, nó thường là một tập hợp các URL, phương thức HTTP, tiêu đề, thân yêu cầu, định dạng phản hồi và điều kiện lỗi.

Định nghĩa này hữu ích hơn so với phép loại suy về nhà hàng quen thuộc vì nó cho biết cho kỹ sư những gì cần kiểm tra. API là lời hứa mà nhà cung cấp thực hiện với người tiêu dùng. Nó có thể mô tả một truy vấn nhanh, một lệnh thay đổi trạng thái hoặc một công việc bất đồng bộ. Tích hợp thành công có nghĩa là tuân theo lời hứa đó và xác minh kết quả mong đợi, thay vì chỉ nhận bytes từ máy chủ.

Giao diện là một hợp đồng

Hợp đồng API xác định các hoạt động tồn tại và cách người gọi có thể sử dụng chúng. Đối với một hoạt động từ xa, hợp đồng có thể bao gồm điểm cuối, phương thức, các trường yêu cầu, giá trị chấp nhận, phương thức thông tin xác thực, sơ đồ phản hồi và các lỗi có thể xảy ra. Nó cũng có thể mô tả phân trang, giới hạn tỷ lệ, phiên bản và trạng thái bất đồng bộ. Một người tiêu dùng nên coi mỗi điều đó là một phần của cùng một giao diện, vì việc bỏ qua một điều có thể thay đổi ý nghĩa của một yêu cầu dường như hợp lệ.

N Cụm từ OpenAPI cung cấp cho các nhóm một cách mô tả có thể đọc được bằng máy để mô tả các đường dẫn API HTTP, các hoạt động, tham số, thân yêu cầu, phản hồi và các phương án bảo mật. Một tài liệu mô tả giúp công cụ, nhưng nó không phải là một sự thay thế cho việc quan sát dịch vụ. Ví dụ có thể bỏ qua các trường tùy chọn hoặc các trường hợp ngoại lệ. So sánh đặc tả với một phản hồi thực và giữ các bài kiểm tra chấp nhận liên kết với các trường mà ứng dụng thực sự sử dụng.

Các hợp đồng tốt tách biệt hành vi công khai ổn định khỏi việc thực hiện riêng tư. Một nhà cung cấp có thể thay thế cơ sở dữ liệu hoặc công nhân nội bộ trong khi vẫn giữ nguyên yêu cầu và ý nghĩa phản hồi bên ngoài. Một người tiêu dùng nên tránh phụ thuộc vào thứ tự trường trong JSON, độ trễ ngẫu nhiên hoặc một chuỗi lỗi không có tài liệu. Những chi tiết đó có thể thay đổi mà không cần thay đổi phiên bản API chính thức vì chúng chưa bao giờ là một phần của lời hứa.

Cách mà một cuộc gọi API Web di chuyển qua HTTP

Một khách hàng đầu tiên chọn một hoạt động và xây dựng một yêu cầu. Phương thức biểu thị một danh mục hành động, URL mục tiêu xác định tài nguyên hoặc hoạt động, các trường tiêu đề mang theo siêu dữ liệu, và thân yêu cầu có thể mang dữ liệu đầu vào có cấu trúc. Máy chủ phân tích tin nhắn, đánh giá thông tin xác thực và đầu vào, thực hiện công việc và gửi phản hồi. Các tiêu chuẩn ngữ nghĩa HTTP định nghĩa ý nghĩa chung của các phương thức, mã trạng thái và các trường; mỗi hợp đồng sản phẩm thu hẹp những khả năng đó về các hoạt động của riêng nó.

Hãy xem xét một khách hàng yêu cầu dữ liệu web công khai có cấu trúc. Họ có thể gửi một yêu cầu đã xác thực đặt tên nguồn đã chọn và đầu vào của nó. Một nhà cung cấp có thể trả về kết quả ngay lập tức hoặc trả về một định danh nhiệm vụ để lấy sau. Một phản hồi 201 hoặc 202 có thể có nghĩa là một hoạt động đã được chấp nhận chứ không phải đã hoàn thành. Đọc bao bì phản hồi được tài liệu trước khi quyết định trạng thái nội bộ nào để ghi lại.

Vận chuyển, kết quả HTTP và kết quả kinh doanh nên được ghi lại riêng biệt. Một lỗi DNS có nghĩa là không có phản hồi HTTP nào đến. Một HTTP 401 có nghĩa là dịch vụ đã từ chối xác thực. Một phản hồi HTTP thành công vẫn có thể chứa một kết quả kinh doanh trống hoặc không đầy đủ. Giữ tách biệt những lớp này khiến việc chẩn đoán hoạt động khả thi và ngăn ngừa mã từ việc lưu trữ một trang đăng nhập như một bản ghi được trích xuất.

Các loại API và khi nào mỗi loại phù hợp

Một API thư viện là một giao diện lập trình cục bộ: các hàm và kiểu được gọi trong một quá trình. Một API trình duyệt hiển thị các khả năng như chọn DOM hoặc yêu cầu mạng cho mã trang. Một API hệ điều hành hiển thị các tệp, quy trình hoặc thiết bị. Một API từ xa vượt qua ranh giới mạng. Tính năng chung là một cách đã được tài liệu để một thành phần sử dụng thành phần khác; từ API một mình không ngụ ý JSON, REST hoặc thậm chí cả HTTP.

Các API web cũng khác nhau về phong cách. Các giao diện HTTP định hướng tài nguyên thường hiển thị các tài nguyên có thể truy cập với các phương thức tiêu chuẩn. GraphQL hiển thị các hoạt động trên một sơ đồ và một lựa chọn các trường. API sự kiện gửi thông báo hoặc luồng khi có điều gì đó thay đổi. Một hệ thống đơn lẻ có thể kết hợp các phong cách: một cuộc gọi gửi một công việc, một cuộc gọi khác đọc trạng thái hiện tại của nó, và một webhook thông báo hoàn thành. Chọn phong cách mà các đảm bảo của nó phù hợp với quy trình làm việc thay vì coi một từ viết tắt nào đó như một nhãn chất lượng.

Một so sánh nên tập trung vào nhiệm vụ của người tiêu dùng. Nếu một bản ghi sản phẩm công khai có thể được truy xuất qua một điểm cuối tài liệu chính thức, hãy sử dụng giao diện đó khi các điều khoản của nó cho phép. Nếu dữ liệu chỉ có sẵn dưới dạng một trang được kết xuất, một dịch vụ dữ liệu web có thể cung cấp trang hoặc sự trích xuất có cấu trúc. Nếu một trình duyệt phải nhấp qua một quy trình công khai nhiều bước, tự động hóa trình duyệt trở nên có liên quan. Lựa chọn thu thập thông tin đến trước khi viết các bộ chọn trường.

Xác thực, Ủy quyền và Ý nghĩa Lỗi

Xác thực cho nhà cung cấp biết ai là người gọi đã trình bày một thông tin xác thực. Ủy quyền xác định liệu người gọi đó có thể thực hiện một thao tác cụ thể hay không. Một khóa API có thể xác định một tài khoản hoặc ứng dụng, nhưng nó không tự động cấp quyền cho mọi khả năng. Hướng dẫn khóa không chạm tài liệu tiêu đề chính xác cho các yêu cầu REST liên quan và cảnh báo về việc không để lộ khóa trong mã phía khách. Theo phương thức hiện tại của sản phẩm đã chọn thay vì đoán một tiêu đề có vẻ chuẩn.

Phản hồi lỗi thuộc về hợp đồng. Khách hàng nên phân biệt giữa đầu vào bị lỗi, thông tin xác thực bị thiếu, quyền truy cập không đủ, tài nguyên bị thiếu, hạn chế tỷ lệ và thất bại dịch vụ khi API tài liệu những kết quả đó. Đừng phân tích mọi nội dung thất bại như thể nó có sơ đồ thành công. Một tích hợp an toàn đầu tiên kiểm tra trạng thái và loại phương tiện mong đợi, sau đó diễn giải nội dung cụ thể của hoạt động. Nếu dịch vụ trả về trạng thái tác vụ, hãy đọc trạng thái đó trước khi coi kết quả là cuối cùng.

Xử lý lỗi phải duy trì đủ ngữ cảnh để sửa chữa yêu cầu mà không ghi lại bí mật. Giữ nguyên tên hoạt động, định danh yêu cầu an toàn, trạng thái và thông điệp phản hồi đã bị làm mờ. Tránh ghi lại tiêu đề xác thực đầy đủ hoặc dữ liệu trang nhạy cảm. Khi một nhà cung cấp ghi lại ID yêu cầu, hãy giữ nó cho hỗ trợ. Một báo cáo lỗi hữu ích xác định trường hợp hợp đồng bị lỗi thay vì biến mọi vấn đề thành "API không khả dụng."

Một Ví Dụ API Không Thể Bị Cắt Bê Tông

The Giới thiệu về API Scraping mô tả các yêu cầu được chọn bởi diễn viên cho các nguồn web được hỗ trợ. Diễn viên xác định gia đình thao tác; đối tượng đầu vào của nó cung cấp các tham số cụ thể cho nguồn. Dịch vụ trả về đầu ra có cấu trúc mà các trường của nó phụ thuộc vào diễn viên. Đây là hợp đồng API trong hành động: người gọi chọn một thao tác và xác thực hình dạng được trả về mà không sở hữu hạ tầng tập hợp.

Một ứng dụng tiêu thụ những kết quả đó vẫn cần một sơ đồ cho các hồ sơ của riêng nó. Giả sử nó cần một tiêu đề, URL nguồn và thời gian quan sát. Phản hồi của diễn viên có thể chứa những giá trị đó ở các vị trí lồng nhau khác nhau cho các nguồn khác nhau. Liệt kê từng diễn viên được hỗ trợ một cách cụ thể, đánh dấu các trường tùy chọn là tùy chọn, và từ chối một phản hồi thiếu các trường yêu cầu bởi trường hợp sử dụng ở hạ nguồn. Một trình phân tích JSON chung chỉ chứng minh rằng văn bản đã trở thành các giá trị trong bộ nhớ.

Các Tổng quan về API scraping giải thích bề mặt dữ liệu có cấu trúc, trong khi các Hướng dẫn diễn viên Scraper API cho thấy tại sao các endpoint và kết quả bao bọc khác nhau theo từng 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 bài kiểm tra chấp nhận hẹp. Mở rộng sang một diễn viên khác chỉ sau khi sơ đồ thứ hai đã được kiểm tra theo các điều kiện của nó.

Cách Đánh Giá Một API Trước Khi Phụ Thuộc Vào Nó

Viết một danh sách kiểm tra tích hợp ngắn trước khi lập trình: hành động bạn cần, điểm cuối hiện tại, cách gửi thông tin xác thực, đầu vào cần thiết, trường đầu ra, phản hồi lỗi, và cách hoàn thành được báo hiệu. Xác định những chi tiết nào là hành vi đã được tài liệu ổn định và những gì chỉ là ví dụ. Kiểm tra xem ứng dụng của bạn có cần dữ liệu lịch sử, dữ liệu trực tiếp, hoặc thông báo sau khi hoàn thành một tác vụ hay không. Những nhu cầu đó ngụ ý các bài kiểm tra chấp nhận khác nhau ngay cả cho cùng một nhà cung cấp.

Tạo một bài kiểm tra hợp đồng nhỏ chống lại một mục tiêu được phép. Bài kiểm tra nên xác nhận kết quả HTTP như mong đợi và dấu hiệu kinh doanh chứng minh kết quả thuộc về mục tiêu đó. Một phản hồi với trạng thái đúng nhưng trang sai hoặc một shell trống nên thất bại. Lưu một ví dụ đã được chỉnh sửa của hình dạng phản hồi cho phát triển, và tránh điều trị các giá trị mẫu minh họa như bằng chứng sống.

Cuối cùng, hãy lập kế hoạch cho sự thay đổi. Các điểm cuối có phiên bản có thể giúp xử lý các thay đổi đột phá, nhưng các trường tùy chọn có thể xuất hiện hoặc biến mất trong một giao diện ổn định khác. Tách biệt mã ánh xạ cụ thể của nhà cung cấp. Theo dõi các trường thiếu, loại phương tiện không mong đợi và trạng thái hoàn thành đã thay đổi. Một sự tích hợp API khỏe mạnh làm cho các giả định của nó trở nên rõ ràng để một thay đổi nhà cung cấp tạo ra một lỗi xác thực rõ ràng thay vì làm hỏng dữ liệu đã lưu.

Kết luận

Một API là một hợp đồng phần mềm cho phép các thành phần hợp tác qua một ranh giới xác định. Những câu hỏi hữu ích là hoạt động gì được cung cấp, đầu vào và thông tin xác thực nào được chấp nhận, cách hoàn thành được đại diện, và đầu ra nào chứng minh rằng mục tiêu kinh doanh đã được đạt được. Coi những câu trả lời đó như là các yêu cầu có thể được kiểm tra cho mỗi sự tích hợp.