REST API là gì?

API Scraping không bị rác phơi bày các hoạt động HTTP đã được tài liệu mà các ứng dụng sử dụng để yêu cầu dữ liệu web có cấu trúc.

REST API là một giao diện được thiết kế xung quanh Chuyển trạng thái đại diện, một phong cách kiến trúc cho các hệ thống mạng. REST mô tả các ràng buộc về các tương tác thay vì một URL hoặc định dạng dữ liệu cụ thể. Tài nguyên có các định danh, các khách hàng trao đổi các đại diện, và một giao diện đồng nhất cho phép các thành phần hiểu thông điệp mà không cần biết mọi quy trình đặc thù cho ứng dụng.

Nhiều dịch vụ được gọi là REST API vì chúng sử dụng HTTP và JSON. Những thành phần này một mình không phải là định nghĩa. Câu hỏi hữu ích là cách mà giao diện sử dụng danh tính tài nguyên, ngữ nghĩa phương thức tiêu chuẩn, tương tác không trạng thái, thông tin bộ nhớ đệm, và các liên kết giữa các trạng thái ứng dụng. Nhìn vào những lựa chọn đó giúp một nhóm đánh giá một API hiện có mà không tranh luận về một nhãn hiệu.

Tài nguyên và Đại diện

Một tài nguyên là một khái niệm có thể được xác định, chẳng hạn như sản phẩm, báo cáo hoặc bộ sưu tập. Một đại diện là hình thức thông điệp được truyền tải để mô tả trạng thái hiện tại của nó. Đối tượng cơ sở dữ liệu nội bộ của máy chủ không nhất thiết được phơi bày trực tiếp. Chương kiến trúc REST của Roy Fielding giải thích cách mà tài nguyên và đại diện phù hợp với giao diện đồng nhất.

Một khách hàng có thể yêu cầu một tài nguyên báo cáo và nhận được JSON với trạng thái và liên kết của nó. Một khách hàng khác có thể nhận một đại diện khác nếu API hỗ trợ điều đó. Danh tính tài nguyên vẫn ổn định trong khi đại diện có thể thay đổi theo thời gian. Sự phân biệt này giúp giải thích tại sao một API nên tài liệu hóa ý nghĩa của các định danh và loại phương tiện, thay vì giả định rằng mọi đối tượng JSON là tài nguyên tự nó.

Tài nguyên bộ sưu tập cũng cần ngữ nghĩa rõ ràng. Một danh sách báo cáo có thể phơi bày lọc và phân trang, nhưng máy chủ nên định nghĩa thứ tự và ý nghĩa của mã thông báo trang. Một URL mà tình cờ trả về một mảng không phải là tự giải thích. Khách hàng cần đủ chi tiết hợp đồng để di chuyển qua bộ sưu tập mà không âm thầm sao chép hoặc bỏ qua các bản ghi.

Giao diện đồng nhất và Phương thức HTTP

REST nhấn mạnh một giao diện đồng nhất: các thành phần tương tác thông qua ngữ nghĩa thông điệp chung thay vì một ngôn ngữ lệnh tùy chỉnh riêng cho mỗi đối tượng. HTTP cung cấp các phương thức như GET, POST, PUT, PATCH và DELETE, nhưng phương thức được chọn nên phù hợp với hoạt động thực tế. Tiêu chuẩn ngữ nghĩa HTTP định nghĩa ý nghĩa của các phương thức và thuộc tính phản hồi liên quan.

GET được thiết kế để lấy một đại diện mà không yêu cầu thay đổi trạng thái như mục đích của hoạt động. Một điểm cuối chỉ đọc mà bí mật tính phí một đơn hàng hoặc xóa một bản ghi vi phạm kỳ vọng của khách hàng ngay cả khi URL của nó trông gọn gàng. POST hỗ trợ xử lý theo ngữ nghĩa của tài nguyên; PUT biểu thị việc thay thế đại diện tài nguyên mục tiêu. Lựa chọn đúng phụ thuộc vào hợp đồng thực tế, không phải một bảng nhớ được sao chép vào tài liệu thiết kế.

Ngữ nghĩa phương thức cũng ảnh hưởng đến các trung gian, bộ nhớ đệm và công cụ khách hàng. Một bộ nhớ đệm có thể lý luận về phản hồi GET khác với một hoạt động ghi. Một API mà đặt mọi hành động phía sau POST có thể hoạt động nhưng từ bỏ một số từ vựng chung đó. Ngược lại, ép buộc một hoạt động vào GET chỉ để trông như RESTful có thể tạo ra một vấn đề ngữ nghĩa nghiêm trọng hơn.

Tương tác không trạng thái và Trạng thái ứng dụng

Trong REST, mỗi yêu cầu mang theo thông tin cần thiết để máy chủ hiểu nó mà không dựa vào trạng thái hội thoại được lưu trữ từ yêu cầu trước đó. Không trạng thái không có nghĩa là máy chủ không thể lưu trữ các bản ghi sản phẩm hoặc dữ liệu tài khoản. Nó có nghĩa là tương tác là tự chứa liên quan đến trạng thái ứng dụng hiện tại của khách hàng. Phân tích của Fielding liên kết tính chất đó với khả năng nhìn thấy và khả năng mở rộng.

Xác thực vẫn có thể tồn tại. Một khách hàng có thể gửi một thông tin xác thực trong mỗi yêu cầu trong khi máy chủ duy trì cơ sở dữ liệu người dùng. Một con trỏ hoặc định danh nhiệm vụ cũng có thể xác định một tài nguyên được tạo ra trước đó, miễn là yêu cầu mới làm cho ngữ cảnh của nó rõ ràng. Ranh giới quan trọng: một máy chủ yêu cầu khách hàng phát hành “bước hai” trong khi nhớ “bước một” không được đặt tên để tạo ra sự kết nối phiên ẩn.

Các yêu cầu không trạng thái dễ dàng hơn để kiểm tra riêng biệt, nhưng chúng có thể mang theo siêu dữ liệu lặp lại. Đó là một sự đánh đổi, không phải là lý do để tuyên bố rằng mọi yêu cầu đều rẻ. Giữ thông tin xác thực được bảo vệ và tránh lưu trữ các giá trị nhạy cảm trong các URL mà di chuyển qua nhật ký. Một định danh tài nguyên có thể tham chiếu đến dữ liệu máy chủ trong khi khách hàng vẫn gửi tất cả thông tin cần thiết để giải quyết hoạt động dự định.

Khả năng lưu trữ và Ý nghĩa phản hồi

REST bao gồm các ràng buộc bộ nhớ đệm vì các phản hồi tái sử dụng có thể giảm công việc mạng. Máy chủ nên giao tiếp khi một đại diện có thể được tái sử dụng và trong điều kiện nào. Hướng dẫn bộ nhớ đệm HTTP giải thích các cơ chế tươi mới và xác thực. Một API trả về JSON vẫn có thể hưởng lợi từ các điều khiển bộ nhớ đệm khi dữ liệu và mô hình phân quyền cho phép chúng.

Một phản hồi danh mục công cộng và một số dư tài khoản cá nhân cần các chính sách bộ nhớ đệm khác nhau. Nếu một phản hồi phụ thuộc vào việc phân quyền hoặc tiêu đề yêu cầu, thiết kế bộ nhớ đệm phải phản ánh sự phụ thuộc đó. Tái sử dụng không chính xác có thể rò rỉ thông tin hoặc trình bày dữ liệu lỗi thời như hiện tại. Khả năng lưu trữ do đó là một quyết định sản phẩm và bảo mật, không phải là một chỉ dẫn phổ quát để lưu trữ mọi GET.

Mã trạng thái nên mô tả kết quả của yêu cầu. Một 200 với một đối tượng lỗi cho mọi sự cố có thể làm giảm tính hữu dụng của các khách hàng tổng quát và khả năng quan sát. Một trạng thái đơn thuần cũng không đủ: phần nội dung phản hồi phải giải thích các chi tiết cụ thể cho ứng dụng khi cần. Thiết kế cả hai lớp cùng nhau, sau đó tài liệu hóa những gì khách hàng nên làm với một bộ sưu tập trống, một tài nguyên bị thiếu hoặc một tác vụ bất đồng bộ được chấp nhận.

REST, RPC, và Dữ liệu API Hướng đến Nhiệm vụ

Một API kiểu RPC công khai các thao tác được đặt tên, thường thông qua một điểm cuối hoặc trường hành động chung. Một API hướng REST công khai trạng thái tài nguyên thông qua giao diện đồng nhất. Cả hai đều có thể là thiết kế hợp lệ. Sự phân biệt là về câu semantics tương tác hơn là chất lượng. Gọi một điểm cuối hành động là REST không khiến nó trở nên hướng tài nguyên, và gọi nó là RPC không làm cho nó không phù hợp với một nhiệm vụ xác định.

Cái Giới thiệu API Scrapeless Scraping mô tả các thao tác được chọn bởi diễn viên cho dữ liệu có cấu trúc. Yêu cầu của nó sử dụng một diễn viên để chọn một nhiệm vụ. Giao diện cụ thể đó nên được mô tả bởi hợp đồng HTTP đã được tài liệu hóa của nó; nó không cần phải bị ép buộc vào một nhãn REST sách giáo khoa. Mã khách hàng nên theo dõi thao tác thực tế, đầu vào và hình dạng kết quả.

Một thao tác dựa trên nhiệm vụ có thể trả về một định danh nhiệm vụ để lấy kết quả sau này. Khách hàng nên biết liệu họ đang xem một xác nhận gửi hay dữ liệu đã hoàn thành. Một thiết kế hướng tài nguyên có thể mô hình hóa nhiệm vụ đó như một tài nguyên, nhưng điểm thực tiễn chính là sự rõ ràng trong vòng đời. Cái Hướng dẫn diễn viên API Scraper minh họa lý do tại sao gia đình diễn viên và phong bì kết quả phải được diễn giải tách biệt.

Cách Xem Xét Hợp Đồng API REST

Lấy một quy trình đại diện và vẽ các tài nguyên mà nó chạm tới. Xác định URL cho mỗi tài nguyên, các phương thức được phép, các trường đại diện và mã trạng thái cho các trường hợp thất bại mong đợi. Rồi hỏi liệu một yêu cầu có thể được hiểu độc lập hay không. Bài tập này hữu ích hơn là đếm bao nhiêu đường dẫn URL chứa danh từ.

Kiểm tra các liên kết và chuyển trạng thái. Nếu một phản hồi cung cấp con trỏ trang tiếp theo hoặc URL kết quả nhiệm vụ, khách hàng có thể theo dõi một con đường đã được tài liệu hóa thay vì xây dựng các lộ trình không được tài liệu. Nếu API yêu cầu khách hàng biết các quy tắc sắp xếp ẩn, hãy tài liệu hóa hoặc thiết kế lại sự phụ thuộc đó. Các ràng buộc giao diện đồng nhất mang lại giá trị thực tiễn khi một khách hàng có thể sử dụng ngữ nghĩa thông điệp thay vì đảo ngược kỹ thuật nội bộ của máy chủ.

Cuối cùng, xác minh giao diện với các phản hồi thực từ một môi trường được ủy quyền. Một ví dụ về lược đồ có thể mô tả hành vi dự kiến, nhưng chỉ một trạng thái trả về, tập hợp tiêu đề và thân thể cho thấy những gì dịch vụ đã triển khai thực hiện. Đối với API Scrapeless Scraping, bắt đầu với tài liệu hiện tại của sản phẩm và một quy trình diễn viên hẹp. Đừng suy luận các trường hoặc điểm cuối không được hỗ trợ từ ý tưởng tổng quát về REST.

Kết luận

Một API REST áp dụng các ràng buộc kiến trúc cho các tương tác tài nguyên: danh tính rõ ràng, đại diện, giao diện đồng nhất, yêu cầu không trạng thái, và hành vi bộ nhớ đệm có ý nghĩa. HTTP và JSON là các công cụ phổ biến để triển khai những ý tưởng đó, nhưng không một cái nào chứng minh sự tuân thủ một cách độc lập. Đánh giá một API dựa trên hợp đồng quan sát được của nó và quy trình mà nó hỗ trợ.