Những ứng dụng hàng ngày bạn sử dụng như Google Maps, Spotify, Instagram, ngân hàng của bạn đều được vận hành bởi một thứ mà có lẽ bạn chưa từng thấy nhưng lại vô cùng cần đến. Đó là API. Và đã đến lúc bạn cần nắm vững chủ đề này.
Nếu bạn mới bắt đầu học lập trình, API là một trong những thuật ngữ bạn có thể nghe rất nhiều, như thể ai cũng biết nó nghĩa là gì. Nhưng thực tế, nhiều người lại không biết.
Đến cuối bài viết này, bạn sẽ hiểu cách API hoạt động, ý nghĩa của các thành phần khác nhau và sẽ có một mô hình tư duy để thực sự bắt đầu xây dựng ứng dụng với chúng. Đó là mục tiêu của bài viết này.
Phép so sánh với nhà hàng
Bạn bước vào một nhà hàng. Bạn không tự mình vào bếp, lấy nguyên liệu và tự nấu ăn. Điều đó sẽ rất hỗn loạn! Thay vào đó, bạn ngồi vào bàn, xem thực đơn và nói với người phục vụ món bạn muốn gọi. Người phục vụ sẽ vào bếp, chuyển đơn đặt hàng của bạn, nhà bếp chế biến món ăn, và người phục vụ sẽ mang trở lại bàn của bạn.
Bạn không bao giờ nhìn thấy nhà bếp. Bạn không biết thức ăn được chế biến như thế nào. Bạn chỉ nhận được những gì bạn yêu cầu.
Phiên bản API của cái này
Bạn là nhà phát triển. Máy chủ là nhà bếp chứa tất cả dữ liệu và logic. API là người phục vụ. Nó nhận yêu cầu của bạn, truy cập nơi lưu trữ dữ liệu và mang về chính xác những gì bạn yêu cầu. Bạn không bao giờ tương tác trực tiếp với máy chủ. Người phục vụ, tức là API, xử lý mọi thứ ở giữa.
Vậy thôi. Toàn bộ vấn đề nằm ở đó. API (Giao diện lập trình ứng dụng) là một trung gian cho phép hai hệ thống khác nhau giao tiếp với nhau một cách có cấu trúc.
Ví dụ thực tế
Hãy nghĩ về cách Zomato hiển thị vị trí của một nhà hàng trên bản đồ. Zomato không có hệ thống bản đồ riêng. Việc xây dựng một hệ thống từ đầu là không khả thi. Thay vào đó, nó sử dụng Google Maps thông qua API.
Khi bạn mở trang thông tin nhà hàng, ứng dụng Zomato sẽ gửi yêu cầu đến API Bản đồ của Google: “Hãy cung cấp cho tôi bản đồ cho địa chỉ này.” API của Google sẽ phản hồi bằng dữ liệu bản đồ. Zomato sẽ hiển thị nó. Bạn không bao giờ trực tiếp can thiệp vào cơ sở dữ liệu, thuật toán và mã nguồn của Google. API chỉ đóng vai trò là cầu nối an toàn giữa hai bên.
Khi bạn mở ứng dụng thời tiết trên điện thoại, đây là những gì thực sự xảy ra. Ứng dụng của bạn không lưu trữ dữ liệu thời tiết bên trong. Nó gửi một tin nhắn đến dịch vụ thời tiết hỏi: “Thời tiết ở London hiện tại như thế nào?” Dịch vụ thời tiết nhận được yêu cầu đó, tra cứu dữ liệu và gửi lại phản hồi: nhiệt độ, độ ẩm, tốc độ gió. Ứng dụng của bạn đọc phản hồi đó và hiển thị trên màn hình.
Toàn bộ quá trình hội thoại giữa ứng dụng của bạn và máy chủ diễn ra thông qua API.
API chỉ đơn giản là một bản hợp đồng. Ứng dụng của bạn đồng ý yêu cầu thông tin theo một cách cụ thể, và máy chủ đồng ý phản hồi theo một cách cụ thể. Cả hai bên đều tin tưởng vào định dạng đã thỏa thuận.
Cách thức hoạt động thực tế của một yêu cầu
Khi ứng dụng của bạn giao tiếp với API, nó sẽ gửi một thứ gọi là yêu cầu HTTP. Hãy tưởng tượng nó giống như một bức thư có cấu trúc. Nó có một định dạng cụ thể và máy chủ biết chính xác cách đọc nó. Đây là quy trình cơ bản:
Nhấn Enter hoặc nhấp chuột để xem hình ảnh ở kích thước đầy đủ.
Nguồn: Hình ảnh do tác giả cung cấp
Một yêu cầu HTTP có một vài thành phần quan trọng. Đầu tiên là điểm cuối (endpoint), tức là địa chỉ URL cụ thể mà bạn đang truy cập . Thứ hai là phương thức, tức là hành động bạn muốn thực hiện. Thứ ba là các tiêu đề (headers), mang theo thông tin bổ sung. Và đôi khi có cả phần thân (body), chứa dữ liệu thực tế mà bạn đang gửi. Bốn phương thức HTTP mà bạn sẽ sử dụng thường xuyên là:
GET LẤY
Đọc một cái gì đó. Lấy dữ liệu. “Cho tôi một danh sách các bài hát.” Bạn chỉ đang đọc chứ không chỉnh sửa gì cả.
POST BƯU KIỆN
Tạo nội dung mới. Gửi dữ liệu để tạo bản ghi mới. “Thêm bài hát mới này vào cơ sở dữ liệu.”
PUT ĐẶT
Cập nhật cái gì đó. Thay thế một bản ghi hiện có. “Thay đổi tiêu đề bài hát số 10.”
DELETE XÓA BỎ
Xóa bỏ một thứ gì đó. Xóa một bản ghi hiện có. Thao tác này không thể đảo ngược, vì vậy hãy cẩn thận.
Bốn thao tác này kết hợp lại tạo nên khái niệm CRUD trong kỹ thuật: Tạo, Đọc, Cập nhật, Xóa.
Các loại API
API không phải là một thứ duy nhất. Nó là một loại. Giống như một phương tiện giao thông. Nó có thể là một chiếc xe đạp, một chiếc xe tải, và một chiếc xe đua Công thức 1. Tất cả đều là phương tiện nhưng chúng hoạt động rất khác nhau và bạn sẽ sử dụng chúng trong những tình huống hoàn toàn khác nhau. API cũng vậy. Có nhiều loại, và việc biết nên sử dụng loại nào và tại sao là rất quan trọng.
Chúng ta hãy cùng xem xét từng cái một.
1) REST
REST (Representational State Transfer) là kiểu API phổ biến nhất. Nó sử dụng các phương thức HTTP tiêu chuẩn (GET, POST, PUT, DELETE), trả về dữ liệu ở định dạng JSON, và rất dễ xây dựng và hiểu. Khi ai đó nói rằng chúng ta có một API, rất có thể họ đang nói đến một API REST. Vấn đề thực sự duy nhất là đôi khi nó lấy quá nhiều dữ liệu. Điều này có nghĩa là nó cung cấp cho bạn nhiều dữ liệu hơn mức bạn thực sự cần, chẳng hạn như lấy toàn bộ thực đơn pizza trong khi bạn chỉ muốn biết họ có bánh mì tỏi hay không.
2) GraphQL
GraphQL, được phát triển bởi Facebook, giải quyết vấn đề trên. Thay vì máy chủ quyết định dữ liệu bạn nhận được, bạn sẽ cho máy chủ biết chính xác những gì bạn muốn. Không hơn không kém. Nếu bạn chỉ muốn tên người dùng và ảnh đại diện, bạn chỉ cần yêu cầu hai thông tin đó. Đó là một điểm cuối duy nhất nơi bạn viết một truy vấn mô tả chính xác những gì bạn cần.
3) SOAP XÀ PHÒNG
SOAP (Simple Object Access Protocol) ra đời sớm hơn, nghiêm ngặt hơn và sử dụng XML thay vì JSON. Nó có các quy tắc khắt khe về định dạng thông điệp và yêu cầu thiết lập phức tạp hơn nhiều. Ngày nay, bạn hiếm khi xây dựng ứng dụng bằng SOAP từ đầu, nhưng bạn có thể gặp nó nếu làm việc với các hệ thống ngân hàng, dịch vụ chính phủ hoặc phần mềm doanh nghiệp, nơi mà bảo mật và các tiêu chuẩn nghiêm ngặt quan trọng hơn tốc độ.
4) gRPC
gRPC (Google Remote Procedure Call) được xây dựng để đạt tốc độ cao. Thay vì gửi dữ liệu JSON dễ đọc đối với con người, nó gửi dữ liệu ở định dạng nhị phân mà máy móc xử lý nhanh hơn nhiều. Điều này làm cho nó hoàn hảo cho kiến trúc microservices, nơi hàng chục dịch vụ nội bộ giao tiếp với nhau hàng nghìn lần mỗi giây.
API kiểu yêu cầu-phản hồi rất tuyệt khi bạn là người chủ động bắt đầu cuộc hội thoại. Nhưng còn những tình huống mà máy chủ cần thông báo cho bạn, chẳng hạn như có tin nhắn mới đến hoặc giá cổ phiếu thay đổi thì sao? Đó là lúc API thời gian thực phát huy tác dụng.
5) Webhook
Webhook đảo ngược mô hình thông thường. Thay vì ứng dụng của bạn hỏi “có gì xảy ra không?” mỗi vài giây, bạn cung cấp địa chỉ của mình cho máy chủ và nói “bất cứ khi nào có gì xảy ra, hãy thông báo cho tôi”. Sau đó, máy chủ sẽ gửi thông báo đến ứng dụng của bạn ngay khi sự kiện xảy ra, chẳng hạn như thanh toán thành công hoặc biểu mẫu được gửi đi.
6) WebSocket
WebSocket mở ra một kênh hai chiều giữa ứng dụng của bạn và máy chủ. Cả hai phía có thể gửi tin nhắn cho nhau bất cứ lúc nào, mà không cần bên nào phải hỏi trước. Đây là cách các ứng dụng trò chuyện thời gian thực hoạt động, cách bảng điểm thể thao trực tiếp được cập nhật và cách các trò chơi nhiều người chơi duy trì sự đồng bộ.
7) WebRTC
WebRTC (Giao tiếp thời gian thực trên web) tiến thêm một bước nữa. Thay vì có máy chủ trung gian, nó cho phép hai trình duyệt giao tiếp trực tiếp với nhau . Đây là cách hoạt động của các cuộc gọi video trong Google Meet và các cuộc gọi dựa trên trình duyệt. Máy chủ chỉ giúp hai bên tìm thấy nhau ban đầu. Sau đó, dữ liệu được truyền trực tiếp giữa chúng, giúp tốc độ cực nhanh và độ trễ thấp cho cả âm thanh và video.
Ví dụ về Netflix
Có một điều khiến nhiều người ngạc nhiên. API không chỉ dùng để lấy danh sách bài hát hay hiển thị bản đồ. Chúng còn được sử dụng trong việc triển khai và sử dụng các mô hình học máy trong thế giới thực.
Hãy nghĩ về cách Netflix đề xuất chương trình tiếp theo cho bạn. Có một mô hình học máy mạnh mẽ đang chạy ở đâu đó trên đám mây, nó đã học được thói quen xem của bạn. Khi bạn mở Netflix, ứng dụng của bạn gửi một yêu cầu POST đến API chứa dữ liệu JSON với ID người dùng, lịch sử xem và có thể cả thời gian trong ngày. API chuyển dữ liệu đó cho mô hình, mô hình chạy dự đoán và API gửi lại danh sách các chương trình được đề xuất. Màn hình chính của Netflix sẽ hiển thị các chương trình đó. Tất cả điều này diễn ra chỉ trong vòng một giây.
Yêu cầu đó trông như thế nào?
Ứng dụng của bạn → Gửi yêu cầu POST với dữ liệu JSON (bạn là ai, bạn đã xem gì) → truy cập API → gửi đến mô hình học máy trên đám mây → mô hình chạy dự đoán → API gửi lại các chương trình được đề xuất → màn hình của bạn được cập nhật.
Đây là lý do tại sao các framework Python như Flask và Django lại phổ biến trong các nhóm khoa học dữ liệu, vì chúng được sử dụng để đóng gói các mô hình học máy vào một API để phần còn lại của nhóm kỹ thuật có thể sử dụng chúng. Nhà khoa học dữ liệu xây dựng mô hình. API giúp ứng dụng truy cập được mô hình đó. Và bởi vì các API này được lưu trữ trên cơ sở hạ tầng đám mây, cùng một kiến trúc có thể mở rộng để xử lý hàng triệu người dùng trên toàn cầu, định tuyến mỗi yêu cầu đến máy chủ nào khả dụng và gần nhất.
Mã trạng thái
Khi máy chủ phản hồi, nó sẽ gửi một mã trạng thái gồm ba chữ số cùng với dữ liệu. Nắm vững những mã này ngay từ đầu sẽ giúp bạn tiết kiệm hàng giờ gỡ lỗi. Chỉ cần hiểu quy tắc đơn giản này: 2xx là tin tốt, 4xx nghĩa là bạn đã mắc lỗi, 5xx nghĩa là máy chủ đã mắc lỗi.
Nhấn Enter hoặc nhấp chuột để xem hình ảnh ở kích thước đầy đủ.
Hình ảnh do AI tạo ra
Cách bắt đầu làm việc với API
Kiến thức lý thuyết rất quan trọng. Việc thực hành thực tế mới là điều làm nên bậc thầy. Dưới đây là một lộ trình khởi đầu thực tiễn:
1) Tải xuống Postman: Đây là công cụ miễn phí cho phép bạn gửi yêu cầu API mà không cần viết bất kỳ mã nào. Đây là cách nhanh nhất để xem các yêu cầu và phản hồi hoạt động như thế nào trong thời gian thực.
2) Chọn một API công cộng miễn phí để thử nghiệm. OpenWeatherMap, API của GitHub hoặc PokeAPI đều là những lựa chọn tuyệt vời để bắt đầu.
3) Gửi yêu cầu GET đầu tiên. Lấy một số dữ liệu. Quan sát mã trạng thái. Đọc dữ liệu JSON trả về. Làm quen với nó.
4) Hãy thử gửi yêu cầu POST. Tạo một đối tượng nào đó. Xem phản hồi 201. Sau đó, gửi yêu cầu GET đến đối tượng bạn vừa tạo.
5) Hãy thử sử dụng các dịch vụ webhook như Stripe hoặc GitHub, cho phép bạn thiết lập webhook trong bảng điều khiển của họ.
6) Hãy đọc tài liệu hướng dẫn cho bất kỳ API nào bạn đang sử dụng. Tài liệu tốt là người thầy tốt nhất. Hãy làm quen với việc đọc tài liệu vì điều đó sẽ giúp ích cho bạn về lâu dài.
Điều duy nhất cần nhớ
API là nền tảng hoạt động của internet hiện đại. Mỗi ứng dụng bạn sử dụng, chẳng hạn như Swiggy, Instagram, đều liên tục thực hiện các cuộc gọi API ngầm, định tuyến qua các điểm cuối REST, kích hoạt webhook và duy trì kết nối WebSocket. Công việc của bạn với tư cách là một kỹ sư là hiểu cách giao tiếp với các API đó, tự xây dựng chúng và gỡ lỗi khi xảy ra sự cố.
Giờ bạn đã biết API là gì. Bạn đã biết sự khác biệt giữa REST, GraphQL, SOAP, gRPC, Webhooks, WebSockets và WebRTC. Bạn đã biết các điểm cuối (endpoints), mã trạng thái (status codes), khóa API (API keys) và JSON là gì. Giờ bạn đã có kiến thức cần thiết để làm việc với API.
Đó là nhiều hơn những gì hầu hết mọi người biết khi bắt đầu công việc đầu tiên. Hãy thử dùng Postman và gửi yêu cầu đầu tiên của bạn. Đó là nơi quá trình học hỏi thực sự bắt đầu.
Bài viết liên quan: