API web hoạt động như thế nào? [đóng cửa]

Tôi đã nghe nói về nhiều API web như của Facebook, Twitter, v.v., giúp bên thứ ba truy cập dữ liệu và thao tác với nó. Tôi muốn biết API web hoạt động như thế nào. Những điều cơ bản của API web là gì?

Nếu tôi muốn tạo API cho trang web của mình, để mọi người có thể truy cập hoặc cập nhật nó, tôi cần bắt đầu với cái gì?

Đơn giản nhất, bạn tạo một tập hợp các yêu cầu GET / POST mà bất kỳ ai cũng có thể gọi và xuất bản thông tin về các URL, tham số và hiệu ứng. NHẬN yêu cầu cho các tác vụ chỉ đọc và yêu cầu POST cho bất kỳ thứ gì sẽ thay đổi dữ liệu trên máy chủ.

Thêm vào một hệ thống xác thực nếu cần và bạn có cho mình một API Web đơn giản.

Một Web API chỉ là một giao diện cho phép truy cập vào hệ thống của bạn (chẳng hạn như trang web) thông qua tiêu chuẩn phương pháp yêu cầu HTTP . Bản thân dữ liệu thường được gói theo một số định dạng chuẩn (như JSON hoặc XML ) để dễ xử lý.

Dưới đây là một ví dụ Web API cho 'TextWise'

Bây giờ tôi đang thực sự phát triển API cho nền tảng ảo hóa của công ty tôi. Bạn có thể thực hiện chúng theo một số cách khác nhau, nhưng yêu thích của tôi (và cách nhanh nhất để có được thứ gì đó hoạt động mà mọi người có thể hiểu) là sử dụng các yêu cầu HTTP GET đơn giản và trả về phản hồi JSON.

URL của tôi trông giống như thế này:

domain.com/method/call/subcall?key=key&data=something

Sau đó tôi chia nhỏ các biến HTTP GET và làm những gì người gọi muốn thực hiện với chúng. Một trong những lý do lớn nhất mà tôi đã đăng ký với tư cách là người dùng beta để phát triển Stack Exchange API là tôi biết rằng đó sẽ là một trải nghiệm học tập tuyệt vời, và thực sự nó là như vậy .

Thông thường, tôi trả về hai mảng được mã hóa JSON, một mảng, resultvề cơ bản chỉ nói nếu cuộc gọi thành công và đưa ra mã lỗi / chuỗi lỗi nếu không. Cái khác thường chỉ được gọi datavà nội dung của nó được mô tả trong tài liệu của cuộc gọi cụ thể đó. Ngoài ra, các API dựa trên GET dễ dàng hơn để kiểm tra và gỡ lỗi.

Có rất nhiều định dạng khác tồn tại, chẳng hạn như SOAP / XMLRPC, tôi chỉ thấy rằng việc chọn JSON mang lại cho tôi sự đơn giản đáng kinh ngạc và sự tự do lựa chọn.

Chẳng hạn, nếu tôi cần gửi nhiều trường và không muốn xử lý hàng tấn biến GET, tôi chỉ có thể làm điều này (ví dụ trong PHP)

$to_send = base64_encode(json_encode($some_array));

Điều đó dễ dàng được giải mã ở phía bên kia, mang lại cho tôi hàng tá biến để làm việc, trong khi vẫn chỉ chấp nhận 2 - 3 biến GET thông qua API.

Tôi chỉ cố gắng giữ các phương thức của mình và gọi ngắn gọn và cô đọng, và thiết kế nó theo cách mà mỗi cuộc gọi trả về một phản hồi 'làm việc hoặc thất bại' thống nhất, theo sau là dữ liệu được yêu cầu.

Đó thực sự là một câu hỏi rất rộng. Theo nghĩa cơ bản nhất, API web hoạt động khi máy khách (như trình duyệt Web) thực hiện một yêu cầu HTTP nào đó với máy chủ Web. Máy chủ kiểm tra yêu cầu đó để tìm ra những gì người dùng muốn, sau đó trả lại dữ liệu ở một số định dạng (như một trang) mà khách hàng sau đó kiểm tra để có được những gì họ muốn. Đây chỉ là những điều duy nhất mà các API Web có điểm chung; Tôi nhận ra rằng điều này không thực sự trả lời câu hỏi của bạn, nhưng tôi muốn đưa ra lý do tại sao câu hỏi quá rộng.

Có tất cả các cách mà khách hàng có thể định dạng yêu cầu của mình hoặc máy chủ có thể định dạng phản hồi của mình và do đó, để bất kỳ cách nào có ý nghĩa, khách hàng và máy chủ phải đồng ý với một số quy tắc cơ bản. Nói chung, ngày nay có hai phong cách rất chung được sử dụng cho loại điều này.

Cuộc gọi thủ tục từ xa (RPC)

Trong API kiểu RPC, thường chỉ có một URL cho toàn bộ API. Bạn gọi nó bằng cách POST một tài liệu thuộc loại nào đó chứa thông tin về những gì bạn muốn làm và máy chủ trả về tài liệu có những gì bạn muốn. Trong thuật ngữ điện toán chung, tài liệu yêu cầu thường có tên hàm và một số đối số.

Một số tiêu chuẩn cho kiểu API này bao gồm XML-RPC và SOAP. Các tiêu chuẩn này cố gắng tạo một định dạng có thể được sử dụng để mô tả chức năng gọi bạn đang thực hiện hoặc thậm chí để mô tả toàn bộ API.

Chuyển giao nhà nước liên quan (REST)

Trong API kiểu REST, bạn không có nhiều URL cho API dưới dạng không gian tên : máy chủ hoặc thư mục bên trong máy chủ, nơi có rất nhiều đối tượng khác nhau và mọi URL trong không gian tên này trở thành một phần của API. Thay vì nói với máy chủ rằng bạn muốn sử dụng API, URL sẽ cho máy chủ biết bạn muốn sử dụng API trên . Sau đó, bạn sử dụng phương thức HTTP và có thể là cơ quan yêu cầu để giải thích những gì bạn muốn làm với đối tượng đó: GET (lấy một cái gì đó đã có), POST (tạo một cái gì đó mới), PUT (thay thế một cái gì đó đã có), hoặc XÓA (loại bỏ một cái gì đó đã có). Có một vài động từ khác bạn có thể sử dụng, nhưng đó là những động từ phổ biến nhất.

Cho đến nay, tôi đã không đề cập đến các định dạng tiêu chuẩn cho REST. Về lý thuyết, bạn có thể sử dụng bất kỳ định dạng nào. HTTP đã cung cấp để nói những gì bạn muốn làm và những gì bạn muốn làm, vì vậy định dạng của phần yêu cầu có thể là bất cứ thứ gì: một số đại diện của đối tượng bạn muốn tạo hoặc thay thế. Nhưng trong thực tế, các tác giả REST có xu hướng đồng ý về một định dạng, bởi vì sẽ rất khó để hiểu được mọi định dạng có thể.