- vừa được xem lúc

Các loại kiến trúc API phổ biến mà bạn nên biết

0 0 16

Người đăng: Minh Hoàng

Theo Viblo Asia

1. Lời mở đầu

Xin chào mọi người 👋👋👋

Trong quá trình làm việc với API, có lẽ do sự phổ biến của REST API mà ta quên đi sự tồn tại của các loại API khác. Và để hòa chung bầu không khí MayFest2023 thì mình sẽ cùng với mọi người tìm hiểu xem các kiến trúc API phổ biến hiện nay, để có cái nhìn tổng thể hơn về API nhé 😄

2. API là gì?

Khái niệm này không còn quá xa lạ với lập trình viên nữa rồi nhỉ. Mình cũng đã có một bài viết về chủ đề API, nếu cần ôn bài, các bạn có thể xem lại tại đây :v

3. API architecture

Vậy thì kiến trúc API mà mình nhắc đến ở trên rốt cuộc là cái gì?

Kiến trúc API là một tập hợp các quy tắc và tiêu chuẩn được sử dụng để thiết kế các ứng dụng phần mềm để tương tác với nhau thông qua các giao diện lập trình ứng dụng (API).

Với kiến trúc API, các nhà phát triển có thể tạo ra các ứng dụng mà không cần biết chi tiết về các phần khác của hệ thống, chỉ cần tương tác thông qua API. Điều này làm cho việc xây dựng ứng dụng dễ dàng hơn và giảm thiểu sự phụ thuộc giữa các phần của hệ thống.

4. API architecture styles

Các kiểu kiến trúc API (API architecture styles) là những kiểu kiến trúc chung được sử dụng để thiết kế các API. Các kiểu kiến trúc này cung cấp một cách tiếp cận chuẩn hóa để thiết kế và triển khai các API, giúp cho các nhà phát triển có thể dễ dàng phát triển, tương tác và quản lý các ứng dụng của họ.

Theo báo cáo State of the API 2022 của Postman, các kiểu kiến trúc API phổ biến nhất là:

Dựa vào kết quả này, ta có thể thấy kết quả cho tới thời điểm hiện tại (tháng 5 năm 2023) không thay đổi quá nhiều. Mình sẽ nêu ra những ưu nhược điểm của vài kiểu kiến trúc API mà mình thấy nó ở vị trí top nhá :v

REST

image.png

REST chiếm con số 89% ở báo cáo trên. Vậy REST là gì mà nó lại được ưa chuộng vậy nhỉ?

REST là viết tắt của Representational State Transfer, là một kiến trúc phần mềm dựa trên các giao thức web chuẩn như HTTP, URL và JSON. Kiến trúc RESTful API được thiết kế để cung cấp khả năng tương tác với các nguồn tài nguyên một cách đơn giản và hiệu quả.

Về ưu điểm của kiến trúc REST:

  • RESTful API sử dụng các phương thức HTTP chuẩn, giúp các nhà phát triển dễ dàng tương tác và thao tác trên các nguồn tài nguyên.
  • Kiến trúc RESTful API có khả năng mở rộng tốt, dễ dàng triển khai, duy trì và quản lý.
  • RESTful API cho phép tách biệt giữa client và server, giúp tăng tính tái sử dụng của các phần mềm và giảm độ phụ thuộc giữa client và server.
  • RESTful API hỗ trợ đa nền tảng và khả năng tương thích với nhiều ngôn ngữ lập trình và hệ điều hành khác nhau.

Và về nhược điểm của kiến trúc REST:

  • RESTful API có thể gặp khó khăn trong việc xử lý các hoạt động phức tạp hoặc các thao tác không phù hợp với các phương thức HTTP chuẩn.
  • Các API RESTful không cung cấp các quy định chặt chẽ về định dạng dữ liệu, do đó có thể dẫn đến sự không nhất quán về cách định dạng dữ liệu trong các tài nguyên (nó trả về rất nhiều siêu dữ liệu, có thể làm chậm thời gian phản hồi và sử dụng hết băng thông không cần thiết)

Bạn nên sử dụng kiến trúc REST khi nào?

Kiến trúc RESTful API thường được sử dụng trong các ứng dụng web và di động. Nó là một lựa chọn tốt cho các ứng dụng cần thiết kế để hoạt động trên nhiều nền tảng và thiết bị khác nhau. REST API cũng được sử dụng trong các hệ thống quản lý dữ liệu, các hệ thống phân tán và trong các hệ thống IoT để tương tác với các thiết bị.

Webhooks

image.png

Kiến trúc Webhook là một kiểu kiến trúc API cho phép các ứng dụng web giao tiếp với nhau theo thời gian thực. Thay vì việc thủ công truy vấn API để lấy dữ liệu, Webhook cho phép ứng dụng tự động nhận các cập nhật mới nhất khi sự kiện xảy ra.

Ưu điểm của kiến trúc Webhook bao gồm:

  • Thời gian thực: Webhook cho phép truyền dữ liệu trực tiếp mỗi khi sự kiện xảy ra, giúp các ứng dụng web tương tác với nhau theo thời gian thực.
  • Tiết kiệm tài nguyên: Vì các cập nhật chỉ được gửi khi cần thiết, Webhook giúp tiết kiệm tài nguyên hơn so với việc liên tục truy vấn API để kiểm tra sự thay đổi dữ liệu.
  • Tích hợp dễ dàng: Webhook có tính khả chuyển cao, cho phép tích hợp với các ứng dụng web khác một cách dễ dàng.

Tuy nhiên, nhược điểm của kiến trúc Webhook là:

  • Không đa dạng và không linh hoạt như một API hoàn chỉnh.
  • Nó chỉ đơn giản là một bộ truyền tải dữ liệu một chiều
  • Không có cơ chế đảm bảo tính sẵn sàng của người nhận. Vì vậy bạn sẽ không biết được liệu dữ liệu đang được truyền tải đến đúng địa chỉ hay không

Nên sử dụng kiến trúc Webhook trong các trường hợp cần truyền tải dữ liệu theo thời gian thực và sự kiện xảy ra không định kỳ. Ví dụ: cập nhật trang trạng thái của một đơn hàng, gửi thông báo khi có tin nhắn mới, cập nhật thông tin trạng thái của máy chủ và phần mềm.

SOAP

image.png

SOAP (Simple Object Access Protocol) là một trong những kiến trúc API phổ biến trong việc truyền tải thông tin giữa các ứng dụng khác nhau do World Wide Web Consortium (W3C) định nghĩa. Đây là một giao thức truyền tải dữ liệu dạng XML, được sử dụng để tạo ra các web service.

Về ưu điểm của kiến trúc SOAP:

  • Hỗ trợ tất cả các giao thức internet phổ biến, bao gồm HTTP, SMTP, TCP, và FTP.
  • Hỗ trợ rất nhiều ngôn ngữ lập trình, bao gồm C++, Java, .NET, và Python.
  • Đảm bảo tính toàn vẹn và độ tin cậy cao trong việc truyền tải dữ liệu qua mạng.

Nhược điểm của kiến trúc SOAP bao gồm:

  • Kiến trúc SOAP sử dụng dữ liệu dạng XML nên tốc độ truyền tải chậm hơn so với các kiểu truyền tải dữ liệu khác như JSON.
  • Kiến trúc SOAP có cấu trúc phức tạp, do đó khó khăn trong việc triển khai và xử lý.

Kiến trúc SOAP nên được sử dụng trong các trường hợp cần đảm bảo tính bảo mật, tính toàn vẹn và độ tin cậy cao, ví dụ như trong các ứng dụng quản lý tài khoản ngân hàng hoặc các ứng dụng y tế. Tuy nhiên, nếu bạn đang phát triển các ứng dụng có tính tương tác cao, đòi hỏi tốc độ truyền tải nhanh và cấu trúc dữ liệu đơn giản, thì kiến trúc SOAP có thể không phù hợp.

GraphQL

image.png

GraphQL là một kiến trúc API được phát triển bởi Facebook nhằm đáp ứng nhu cầu tương tác và truy xuất dữ liệu của ứng dụng web và mobile. Khác với kiến trúc REST, GraphQL cho phép người dùng yêu cầu chính xác các trường dữ liệu mà họ muốn, giúp giảm thiểu số lần yêu cầu tới server và tăng tốc độ phản hồi của API.

Về ưu điểm:

  • Tiết kiệm băng thông: Với GraphQL, người dùng chỉ yêu cầu những trường dữ liệu cần thiết, không bao gồm những trường không cần thiết, giảm thiểu sự lãng phí băng thông.
  • Tăng tốc độ truy vấn: GraphQL cho phép yêu cầu nhiều trường dữ liệu trên một truy vấn duy nhất, giúp tối ưu hóa tốc độ phản hồi của API.
  • Mã hoá tĩnh: Mã hoá tĩnh giúp GraphQL phát hiện các lỗi tại thời điểm compile, giúp giảm thiểu sự cố hệ thống và thời gian giải quyết lỗi.
  • Đa ngôn ngữ: GraphQL hỗ trợ nhiều ngôn ngữ, cho phép phát triển ứng dụng đa nền tảng.
  • GraphQL không phụ thuộc vào cơ sở dữ liệu, nghĩa là bạn có thể sử dụng nó với hầu hết mọi cơ sở dữ liệu mà bạn có thể nghĩ đến.

Tuy nhiên, có vài nhược điểm nhỏ của GraphQL:

  • Khó khăn trong quản lý cache: Do khả năng động và linh hoạt của GraphQL trong việc lấy dữ liệu, việc quản lý cache có thể khó khăn hơn so với REST API.
  • Khó khăn trong việc định nghĩa schema: GraphQL yêu cầu định nghĩa schema chính xác và chi tiết để tối ưu hóa hoạt động của API.
  • GraphQL không phải là lựa chọn tốt nhất cho các truy vấn phức tạp, vì quá nhiều truy vấn lồng nhau có thể gây quá tải và tắt hệ thống.

GraphQL thường được sử dụng trong các ứng dụng có yêu cầu phải lấy dữ liệu phức tạp và đa dạng, hoặc ứng dụng có nhu cầu tương tác dữ liệu phân tán từ nhiều nguồn. Nó cũng được sử dụng trong các ứng dụng đòi hỏi tốc độ truy vấn nhanh và giảm thiểu lượng truy vấn tới server.

WebSockets

image.png

Kiến trúc WebSockets là một giao thức truyền tải dữ liệu hai chiều (full-duplex) qua một kết nối mạng đơn giản giữa trình duyệt và máy chủ. Nó cho phép các ứng dụng web thiết lập kết nối liên tục và truyền tải dữ liệu trong thời gian thực, đồng thời giảm thiểu tải cho máy chủ và tăng trải nghiệm người dùng. Kết nối WebSocket cũng nhanh hơn nhiều so với HTTP, do đó chúng là sự lựa chọn tuyệt vời nếu bạn đang tìm kiếm kết nối nhanh nhất có thể.

Một số ưu điểm của kiến trúc WebSockets bao gồm:

  • Truyền tải dữ liệu nhanh và hiệu quả, giảm thiểu tải cho máy chủ so với các phương pháp truyền tải dữ liệu khác như polling.
  • Thiết lập kết nối liên tục, giúp ứng dụng web có thể truyền tải dữ liệu trong thời gian thực và phản hồi nhanh chóng.
  • Được hỗ trợ bởi hầu hết các trình duyệt web hiện đại và các thư viện lập trình, dễ dàng để triển khai.

Một số nhược điểm của kiến trúc WebSockets bao gồm:

  • Có thể gây ra vấn đề bảo mật khi kết nối trực tiếp với máy chủ, vì vậy cần có các biện pháp bảo mật để bảo vệ dữ liệu.
  • Khó để xử lý lỗi và quản lý kết nối, đặc biệt khi số lượng kết nối lớn.
  • Nếu một WebSocket bị ngắt kết nối, không có cân bằng tải hoặc cơ chế để kết nối lại
  • Không thể sử dụng được trên một số mạng chặt chẽ, ví dụ như các mạng công ty hay trường học.
  • Không hỗ trợ bộ nhớ cache

Kiến trúc WebSockets thường được sử dụng trong các ứng dụng cần truyền thông tin thời gian thực (real-time) với tốc độ kết nối cao như trò chuyện trực tuyến, trò chơi trực tuyến, các ứng dụng video và âm nhạc trực tuyến, hệ thống đánh giá thời gian thực và các ứng dụng khác cần truyền thông tin nhanh và chính xác.

gRPC

image.png

gRPC là một kiến trúc API sử dụng RPC (Remote Procedure Call) để truyền tải dữ liệu giữa các ứng dụng. Nó sử dụng Protobuf, một định dạng dữ liệu nhị phân độc lập với ngôn ngữ, giúp tối ưu hóa tốc độ truyền tải dữ liệu và tăng cường hiệu suất.

Nó mang lại một số lợi ích như sau:

  • Tốc độ nhanh hơn: gRPC được xây dựng trên HTTP/2, với đó là hỗ trợ cho multiplexing, nén header, và stream data. Điều này cho phép tốc độ truyền tải dữ liệu nhanh hơn và giảm thiểu lưu lượng mạng.

  • Giảm thiểu độ trễ (latency): Vì gRPC sử dụng HTTP/2 để truyền tải dữ liệu, điều này giúp giảm thiểu độ trễ trong việc truyền tải dữ liệu giữa các service, giúp cho hệ thống hoạt động mượt mà hơn.

  • Tính khả chuyển: Giao thức gRPC được hỗ trợ bởi nhiều ngôn ngữ lập trình, cho phép phát triển đa nền tảng và tích hợp dễ dàng.

  • Hỗ trợ cho stream data: gRPC cho phép truyền tải dữ liệu theo kiểu streaming, cho phép tạo ra các ứng dụng đa kênh.

  • Tính năng mã hóa dữ liệu: gRPC sử dụng Protobuf để mã hóa dữ liệu, đây là một định dạng dữ liệu nhị phân hiệu quả hơn so với JSON hoặc XML. Protobuf cho phép compress dữ liệu và giảm thiểu kích thước gói tin truyền tải, giúp giảm tải băng thông mạng.

Tuy nhiên, có vài nhược điểm nhỏ của gRPC:

  • Sử dụng định dạng Protobuf không phổ biến như JSON, gây khó khăn trong việc đọc và hiểu dữ liệu.
  • Yêu cầu kiến thức chuyên sâu về mạng và lập trình để triển khai gRPC.
  • Cần phải có một môi trường hoạt động đúng để tận dụng được các ưu điểm của gRPC.

Nên sử dụng kiến trúc gRPC khi bạn đang xây dựng các ứng dụng cần tốc độ truyền tải dữ liệu cao, hoặc các ứng dụng real-time cần truyền tải dữ liệu liên tục. gRPC rất được ưa chuộng khi phát triển ứng dụng có kiến trúc microservices. Tuy nhiên, nếu bạn mới bắt đầu hoặc không có nhiều kinh nghiệm về mạng và lập trình, có thể gRPC sẽ không phù hợp với bạn.

5. Tổng kết

Như bạn có thể thấy, có rất nhiều điều cần lưu ý khi sử dụng API, không chỉ riêng REST, mặc dù REST vẫn là kiến trúc dẫn đầu với khoảng cách rất xa so với các kiến trúc khác. Có thể nói rằng khi các giải pháp như microservices, headless và serverless trở nên phổ biến hơn, chúng ta cũng sẽ thấy sự gia tăng về việc sử dụng một số kiến trúc API khác.

Nhìn vào báo cáo thì có thể thấy một vài kiến trúc khác như MQTT, AMQP, Server-Sent Events, EDI/EDA. Tuy nhiên chúng không quá phổ biến và chỉ ứng dụng vào những hệ thống đặc thù nên mình sẽ không nhắc tới ở đây.

Mong rằng, bài viết này có thể giúp bạn hình dung được các kiến trúc API phổ biến khác ngoài kiến trúc REST đã quá quen thuộc, nhờ đó mà có thể đưa ra lựa chọn phù hợp cho hệ thống của bạn trong tương lai 😄

Cảm ơn mọi người đã dành thời gian theo dõi bài viết này 🙇

6. Tài liệu tham khảo

  1. https://nordicapis.com/top-architectural-styles-for-apis-in-2023/
  2. Postman 2022 State of the API Report

Bình luận

Bài viết tương tự

- vừa được xem lúc

Flutter - GetX - Using GetConnect to handle API request (Part 4)

Giới thiệu. Xin chào các bạn, lại là mình với series về GetX và Flutter.

0 0 322

- vừa được xem lúc

API vs WebSockets vs WebHooks: What to Choose?

. Khi xây dựng bất kì một ứng dụng nào, chúng ta đều cần phải có một cơ chế đáng tin cậy để giao tiếp giữa các thành phần của nó. Đây là khi APIs, WebSockets và WebHooks được ứng dụng vào.

0 0 85

- vừa được xem lúc

Sử dụng Fast JSON API serialization trong Ruby on Rails

Ở bài viết này chúng ta sẽ thử tạo 1 project API sử dụng gem fast_jsonapi cho serializer. Đầu tiên là tạo một project API mới. $ rails new rails-jsonapi --database=postgresql --skip-action-mailbox --skip-action-text --skip-spring -T --skip-turbolinks --api. .

0 0 117

- vừa được xem lúc

Test thử ba loại API chụp màn hình Windows

Hiện tại, Windows cung cấp khoảng ba cách để chụp màn hình. Thế thì cái nào là nhanh nhất? Tôi muốn test thử từng cái.

0 0 52

- vừa được xem lúc

Ngừng sử dụng REST cho API — GraphQL là cách tốt hơn

Mở đầu. REST đã được nhiều developers sử dụng để gửi dữ liệu qua HTTP trong khi GraphQL thường được trình bày như một công nghệ thay thế các API REST.

0 0 82

- vừa được xem lúc

Quản lý và sử dụng API trong Nuxt bằng cách sử dụng Repository Pattern

Mở đầu năm mới, à nhầm, mở đầu bài viết. Cái tên NuxtJS chắc hẳn cũng không còn xa lạ gì với những bạn yêu thích VueJS nữa, đương nhiên mình cũng là một chàng trai dành tình yêu to lớn cho frameworks này.

0 0 211