Trong quá trình phát triển phần mềm, API (Application Programming Interface) là một trong những khái niệm quan trọng mà cả backend lẫn frontend developer đều cần phải hiểu rõ.

Backend developer chịu trách nhiệm thiết kế API để cung cấp dữ liệu và logic xử lý từ server, trong khi frontend developer gọi API để truy cập và hiển thị những dữ liệu đó lên giao diện người dùng.

Trong bài viết này, chúng ta không chỉ giải thích API là gì, mà còn đi sâu vào các loại API phổ biến hiện nay như REST, GraphQL, và Webhook, ... Quan trọng hơn, bạn sẽ hiểu được đặc điểm nổi bật của từng loại API, từ cách chúng hoạt động đến lý do chúng được ứng dụng rộng rãi trong từng lĩnh vực cụ thể.

1. API là gì?

API - Application Programming Interface hay Giao diện lập trình ứng dụng, là một tập hợp các định nghĩa và giao thức cho phép các ứng dụng phần mềm giao tiếp và tương tác với nhau. Chắc bạn đã từng nghe về định nghĩa của User Interface (Giao diện người dùng) là nơi mà User sẽ tương tác với ứng dụng của chúng ta, cũng tương tự như thế khi các phần mềm "nói chuyện" với nhau cũng cần thông qua giao diện đặc biệt có tên gọi là API.

Ví dụ công ty của bạn đang xây dựng một ứng dụng giao nhận đồ ăn, ứng dụng này được tạo thành từ nhiều Dịch vụ (Service) khác nhau : Quản lý người dùng, đơn hàng, thanh toán, ... Khi khách hàng thanh toán, dịch vụ Quản lý thanh toán sẽ giao tiếp với dịch vụ Quản lý đơn hàng để cập nhật trạng thái đơn hàng (thanh toán thành công/thất bại), nói một cách khác Payment Service sẽ gọi API của Order Service để cập nhật Order Status.

2. Các giao thức API phổ biến (API Protocol)

Trong bối cảnh công nghệ API liên tục đổi mới và phát triển, một số giao thức trở nên phổ biến trong khi những giao thức khác lại dần bị lãng quên. Theo báo cáo State of the API mới nhất của Postman, với sự tham gia của hơn 40.000 Developer đã cho biết những giao thức API nào đang thu hút nhiều sự quan tâm và được áp dụng nhiều nhất hiện nay.

2.1 REST

REST - Representational State Transfer, là một kiến trúc định nghĩa tiêu chuẩn giao tiếp giữa các hệ thống Web (Web API). Các hệ thống tuân thủ tiêu chuẩn REST thường được gọi là RESTful, có 6 nguyên tắc mà bạn sẽ phải tuân thủ:

• Client-Server: REST tách biệt vai trò của máy khách (client) và máy chủ (server). Máy khách chịu trách nhiệm gửi yêu cầu, trong khi máy chủ xử lý yêu cầu và trả về phản hồi. Điều này giúp phân chia trách nhiệm rõ ràng và cho phép phát triển từng thành phần độc lập.
• Stateless: REST tuân thủ nguyên tắc không trạng thái, nghĩa là mỗi yêu cầu từ máy khách đến máy chủ phải chứa tất cả thông tin cần thiết để hiểu và xử lý yêu cầu. Máy chủ không lưu trữ trạng thái của máy khách giữa các yêu cầu, giúp hệ thống dễ mở rộng và bảo trì hơn.
• Cacheable: Các phản hồi từ máy chủ có thể được gắn cờ để lưu trữ ở bộ nhớ đệm (cache) nếu thích hợp, giúp giảm tải cho máy chủ và cải thiện hiệu suất hệ thống.
• Uniform Interface: REST sử dụng một giao diện đồng nhất để tương tác với các tài nguyên (resource). Giao diện này thường sử dụng các phương thức HTTP tiêu chuẩn như GET, POST, PUT, DELETE, v.v., và các URIs để xác định tài nguyên.
• Layered System: REST cho phép kiến trúc hệ thống được xây dựng thành các lớp, trong đó mỗi lớp có thể thực hiện một nhiệm vụ cụ thể mà không cần biết về các lớp khác. Điều này giúp tăng tính linh hoạt và khả năng mở rộng của hệ thống.
• Code on Demand: REST có thể hỗ trợ tuỳ chọn tải thêm các tính năng về khi Client yêu cầu (khi người dùng click vào) mà không phải tải hết một lần khi bạn mở ứng dụng.

Thông qua các động từ HTTP khác nhau, Client có thể tương tác với một tài nguyên như sau:

• GET /customers: Lấy danh sách các khách hàng
• GET /customer/{id}: Lấy thông tin chi tiết của một khách hàng bằng cách sử dụng mã định danh của họ.
• POST /customers: Khởi tạo khách hàng mới.
• PUT /customers/{id}: Sửa đổi một khách hàng hiện có được xác định bởi ID của họ.
• DELETE /customers/{id}: Xóa một khách hàng bằng ID của họ.

2.2 Webhook

Webhook là một cơ chế cho phép một ứng dụng cung cấp dữ liệu theo thời gian thực cho các ứng dụng khác khi có sự kiện xảy ra. Thay vì yêu cầu liên tục từ client (pulling) để kiểm tra xem có sự kiện mới hay không, webhook sẽ gửi dữ liệu đến một URL cụ thể khi sự kiện đó xảy ra, thường được gọi là "callback URL" hoặc endpoint.

2.3 GraphQL

GraphQL không phải là một ngôn ngữ lập trình mà là một ngôn ngữ truy vấn, giúp định nghĩa các tác vụ như query (truy vấn), mutation (thay đổi) hay subscription (lắng nghe thay đổi) trên một GraphQL Server. GraphQL được thiết kế với các nguyên tắc sau đây:

• Hierarchical: Truy vấn GraphQL sẽ phản ánh mối quan hệ phân cấp, ví dụ: một người dùng có thể có nhiều bài viết, và mỗi bài viết có thể có nhiều bình luận.
• View-centric: Thay vì API quyết định những gì cần trả về, client quyết định họ cần dữ liệu gì và truy vấn GraphQL sẽ phản ánh điều đó.
• Strongly-typed: Mỗi trường và đối tượng trong GraphQL đều có một kiểu dữ liệu xác định rõ ràng, điều này giúp đảm bảo rằng các truy vấn được thực hiện chính xác và các lỗi có thể được phát hiện sớm
• Client-driven: Trong GraphQL, client hoàn toàn kiểm soát những dữ liệu mà họ cần bằng cách xác định các trường cụ thể trong truy vấn. Điều này khác với REST, nơi mà server quyết định những gì sẽ được trả về.
• Introspective: GraphQL có tính năng introspection, cho phép client tự động khám phá schema của API. Client có thể gửi các truy vấn introspection để biết được các kiểu dữ liệu, các trường có sẵn, và các mối quan hệ trong schema của API.
• Version-free: Một trong những nguyên tắc chính của GraphQL là không cần phải duy trì nhiều phiên bản của API. Bởi vì client có thể yêu cầu chính xác dữ liệu họ cần, bạn có thể phát triển và mở rộng API mà không phá vỡ tính tương thích với các client cũ.

{
  user(id: "1") {
    name
    posts {
      title
      comments {
        content
      }
    }
  }
}

2.4 gRPC

Giống các giao thức RPC khác, gRPC (gRPC Remote Procedure Calls) bao gồm một máy chủ (server) định nghĩa các phương thức có thể được gọi từ xa bởi các máy khách (clients). Để đạt được điều này, gRPC giới thiệu khái niệm gRPC client stubs và gRPC servers.

Một tính năng quan trọng của gRPC và là một trong những lý do chính khiến nó trở nên phổ biến trong các kiến trúc microservice, là khả năng hỗ trợ bốn kiểu tương tác sau đây:

1. Unary: gRPC hỗ trợ mô hình Request/Response truyền thống, giúp dễ dàng tích hợp với các hệ thống hiện có sử dụng RPC. Điều này giống với việc bạn yêu cầu thông tin của 100 khách hàng và hệ thống sẽ trả về cho bạn 100 khách hàng, sau đó yêu cầu sẽ được đóng lại.
2. Server streaming: gRPC cho phép máy chủ gửi một luồng dữ liệu liên tục đến máy khách sau khi nhận được yêu cầu, phù hợp với các trường hợp cần truyền dữ liệu theo thời gian thực hoặc khối lượng lớn. Tưởng tượng là bạn đang mở ứng dụng Netflix và chọn xem một bộ phim có nhiều tập với gRPC, Netflix Server gửi một luồng dữ liệu liên tục (các tập phim) đến bạn sau khi bạn đã yêu cầu xem bộ phim. Với REST hay RPC thông thường, sau khi xem xong tập đầu tiên, nếu bạn muốn xem tiếp tập thứ hai, bạn sẽ phải gửi một yêu cầu GET khác đến API để lấy tập tiếp theo. Các bạn có thể đọc thêm về lợi ích của gRPC khi triển khai Microservice.
3. Client streaming: Máy khách có thể gửi một chuỗi các thông điệp đến máy chủ trước khi nhận được phản hồi (ngược lại với ví dụ ở mục 2).
4. Bidirectional streaming: gRPC cho phép giao tiếp hai chiều không đồng bộ giữa máy khách và máy chủ, giúp cả hai có thể trao đổi dữ liệu liên tục và đồng thời, làm tăng tính linh hoạt và hiệu quả trong các ứng dụng cần giao tiếp phức tạp.

3. Kết luận

Qua bài viết vừa rồi mình hy vọng có thể cung cấp cho bạn cái nhìn cơ bản về API và vai trò của nó đối với quá trình phát triển phần mềm, mình sẽ viết chi tiết hơn từng kiến trúc trong những bài viết tiếp theo.

Các bài viết liên quan tại Blog 200Lab:

• OOP là gì? Chi tiết về lập trình hướng đối tượng
• REST API là gì? Cách thiết kế RESTful API bạn chưa biết
• Git cơ bản: Định nghĩa các lệnh Git thường gặp
• WebSocket là gì? Lý do sử dụng WebSocket