Khi bạn chuẩn bị xây dựng API của mình, bạn có thể thấy mình đang thắc mắc nên lựa chọn kiến trúc nào để thiết kế API (Application Programming Interface). Bài viết này sẽ giúp bạn có cái nhìn chung về các kiến trúc API hiện nay.
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 hiện nay là:
- REST (89%)
- Webhooks (35%)
- SOAP (34%)
- GraphQL (28%)
- Websockets (26%)
- gRPC (11%)
- MQTT (9%)
- AMQP (8%)
- Server-Sent Events (6%)
- EDI (4%)
- EDA (3%)
- Other (1%)
REST - Ưu và nhược điểm
REST (REpresentational State Transfer) còn được biết đến là RESTful API là một trong những tiêu chuẩn đầu tiên cho API, như được trình bày trong luận án của Roy Fielding và nó vẫn là một trong những tiêu chuẩn tốt nhất.
REST cũng là phổ biến nhất, cho đến nay , chiếm tới 89% API khổng lồ.
REST là một tiêu chuẩn cho phép người dùng thực hiện các yêu cầu API bằng cách sử dụng các lệnh HTTP đơn giản.
Ưu điểm của kiến trúc của REST cho phép tách rời dễ dàng hơn giữa người dùng và máy chủ, làm cho nó trở nên tuyệt vời cho việc trừu tượng hóa. Nó cũng có thể hỗ trợ nhiều định dạng dữ liệu, vì vậy nó khá linh hoạt cũng như khả năng mở rộng.
Tuy nhiên, REST không phải là không có nhược điểm. Ví dụ, nó trả về rất nhiều siêu dữ liệu (metadata), có thể làm chậm thời gian phản hồi từ máy chủ và sử dụng nhiều băng thông không cần thiết.
Định dạng lớn này, cùng với các vấn đề liên quan đến tìm nạp quá mức và tìm nạp thiếu, là một trong những lý do chính khiến Facebook phát triển GraphQL vào năm 2012.
GraphQL
GraphQL là một ngôn ngữ truy vấn (query language) và một runtime cho việc truy vấn các API. GraphQL được tạo ra bởi Facebook nhằm giải quyết những hạn chế của RESTful API, đặc biệt là về việc truy vấn dữ liệu và định dạng dữ liệu trả về.
GraphQL cung cấp cấu trúc dữ liệu đơn giản, giống như JSON của nó rất dễ hiểu, đơn giản với những người không phải là kỹ thuật viên.
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.
Điều này làm cho GraphQL API của bạn có khả năng mở rộng và linh hoạt vượt trội, tiết kiệm băng thông, khả năng tương thích cao với nhiều nền tảng
Tuy nhiên, 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.
Ngoài ra GraphQL cũng khó khăn cho người mới học hay triển khai vào dự án hiện tại
Webhook
Webhook (hay còn gọi là web callback và HTTP push API) là một công nghệ rất tiện dụng trong việc triển khai các phản ứng sự kiện (event reaction) trên website của bạn.
Webhook cung cấp một giải pháp giúp ứng dụng server-side thông báo cho ứng dụng phía client-side khi có sự kiện phát sinh đã xảy ra trên máy chủ (event reaction).
Đôi khi chúng ta cần tương tác dữ liệu thời gian thực. Có lẽ tốt nhất là ứng dụng nên tự động nhận các bản cập nhật mới nhất thay vì truy vấn API theo cách thủ công. Webhook giải quyết những tình huống này cho bạn.
Có thể sử dụng webhook để gửi dữ liệu bất cứ khi nào một sự kiện mới xảy ra .
Ví dụ: hãy tưởng tượng bạn đã thiết lập một danh sách email mới và muốn cập nhật bất cứ khi nào bạn nhận được đăng ký mới. Webhook có thể truyền dữ liệu đó, giúp bạn tiết kiệm thời gian, công sức và năng lượng khi thực hiện truy vấn. Điều này cũng có thể ngăn lãng phí các tài nguyên không cần thiết khi thực hiện lệnh gọi API khi dữ liệu chưa thay đổi.
Nhược điểm chính của webhook là chúng không linh hoạt hoặc không thể tùy chỉnh như một API chính thức.
Nó chỉ đơn giản là một máy truyền dữ liệu một chiều. Cũng không có dấu hiệu nào cho thấy bộ thu có hoạt động hay không, vì vậy bạn không nhất thiết phải biết liệu dữ liệu được truyền đi có đến được nơi cần đến hay không.
Tuy nhiên, Webhook có đủ loại ứng dụng hữu ích. Bạn sẽ chỉ muốn có sẵn một giải pháp giám sát để đảm bảo rằng bạn được thông báo nếu có sự cố xảy ra.
SOAP
SOAP (Simple Object Access Protocol) là giao thức API cho phép các chương trình chạy trên các hệ điều hành khác nhau (như Windows và Linux) giao tiếp được với nhau thông qua Giao thức HTTP với một cấu trúc định dạng XML được chuẩn hóa bởi W3C .
Đây là định dạng được sử dụng rộng rãi nhất cho các dịch vụ web và hữu ích cho rất nhiều ứng dụng khác nhau.
SOAP hiện đang là nền tảng độc lập với ngôn ngữ độc lập, có thể giao tiếp qua proxy, firewall và có thể truyển tải qua các giao thức HTTP và SMTP cũng như các giao thức khác
SOAP cũng tuyệt vời cho quyền riêng tư, cho phép các thông điệp được mã hóa và tính toàn vẹn bên trong mỗi giao dịch.
Tuy nhiên, SOAP là định dạng tệp lớn nhất do cấu trúc XML dài dòng. SOAP sẽ tốn nhiều băng thông. Đồng thời nó cũng rất cứng nhắc, vì vậy nó không thể tùy chỉnh nhiều, điều này làm chậm chạp đáng kể trong việc áp dụng rộng rãi của nó.
WebSockets
WebSokets là công nghệ hỗ trợ giao tiếp hai chiều giữa client và server bằng cách sử dụng một TCP socket để tạo một kết nối hiệu quả và ít tốn kém. Rất phù hợp với dự án real-time
Giống như webhook, WebSockets cung cấp khả năng truyền dữ liệu theo thời gian thực. Nó cũng có thể nhận dữ liệu, khiến chúng trở thành thứ tốt nhất của cả hai client và server.
Các kết nối WebSockets cũng nhanh hơn nhiều so với HTTP , vì vậy chúng là một lựa chọn tuyệt vời nếu bạn đang tìm kiếm các kết nối nhanh nhất có thể.
Tuy nhiên, WebSockets cũng có vấn đề của nó, điều này giải thích tại sao chúng không phổ biến hơn các loại ở trên.
Nếu WebSocket gặp sự cố, sẽ không có cơ chế cân bằng tải hoặc tự kết nối lại. Chúng cũng không hỗ trợ bộ nhớ đệm, không giống như HTTP.
Nhiều máy chủ proxy cũng không hỗ trợ WebSockets. Điều này có nghĩa là bạn thường phải có cơ sở hạ tầng HTTP song song với WebSockets của mình.
gRPC
gRPC (Google Remote Procedure Call) là một khung RPC nguồn mở được sử dụng để tạo các API nhanh và có thể mở rộng. Nó cho phép phát triển các hệ thống nối mạng và giao tiếp mở giữa các ứng dụng máy khách và máy chủ gRPC.
gRPC đã được một số công ty công nghệ hàng đầu chấp nhận, bao gồm Google, IBM, Netflix ...
Trên thực tế, gRPC nhanh hơn gấp 7 lần so với REST bình thường. gRPC cũng có trình biên dịch mã gốc, loại bỏ nhu cầu sử dụng các công cụ của bên thứ ba giúp nó chạy nhanh hơn nhiều
Tuy nhiên, một điều cần lưu ý là gRPC sử dụng định dạng Protobuf thay vì JSON. Protobuf nhẹ và hiệu quả nhờ khả năng nén dữ liệu của nó. Nó không phải là dễ hiểu bởi con người và cũng không phổ biến như JSON, vì vậy bạn có thể cần phải đặt một trình dịch nếu bạn đang tích hợp các API gRPC vào các môi trường API khác.
gRPC cũng phức tạp và khó triển khai hơn các kiến trúc API khác. Nếu bạn đang tìm kiếm thứ gì đó nhanh và dễ thiết lập, tốt hơn hết bạn nên sử dụng kiểu kiến trúc API khác như REST.
Ngoài các kiến trúc API phổ biến ở trên, còn có các kiến trúc khác như sau:
MQTT
MQTT (Message Queuing Telemetry Transport) là giao thức truyền thông điệp (message) theo mô hình publish/subscribe (cung cấp / thuê bao), được sử dụng cho các thiết bị IoT với băng thông thấp, độ tin cậy cao và khả năng được sử dụng trong mạng lưới không ổn định.
Nó dựa trên một Broker (tạm dịch là “Máy chủ môi giới”) “nhẹ” (khá ít xử lý) và được thiết kế có tính mở (tức là không đặc trưng cho ứng dụng cụ thể nào), đơn giản và dễ cài đặt.
MQTT là một kiến trúc API hữu ích cho các ứng dụng IoT. Nó phổ biến vì nhẹ và sử dụng ít pin. Nó cũng phổ biến vì độ chính xác của thông điệp .
Không giống như các kiểu kiến trúc API khác, MQTT không sử dụng HTTP để gửi hoặc nhận yêu cầu. Thay vào đó, nó sử dụng TCP/IP và mô hình “ publish/subscribe”. Điều này có nghĩa là người nhận cần một Máy chủ môi giới MQTT để tích hợp với thiết bị bằng MQTT, hoạt động như một loại bưu điện để nhắn tin MQTT.
Tuy nhiên, MQTT bị hạn chế về chức năng. Nó chỉ có thể gửi và nhận các yêu cầu và loại tệp cơ bản. Nó cũng không tương tác như REST, thiếu khả năng POST, GET, DELETE hoặc PUT.
Với suy nghĩ này, MQTT chủ yếu phù hợp cho các ứng dụng IoT cụ thể . Nó cũng phù hợp với các tình huống có kết nối hạn chế hoặc băng thông thấp.
AMQP
AMQP (Advanced Message Queuing Protocol) là một giao thức giao tiếp được sử dụng trong các hệ thống tin nhắn. Nó cho phép các hệ thống gửi và nhận tin nhắn một cách chính xác và bảo đảm
AMQP là một kiến trúc API được thiết kế cho microservices.
AMQP là sự kết hợp của một vài kiểu kiến trúc API mà chúng ta đã thảo luận. Ví dụ, nó sử dụng mô hình publish/subscribe của MQTT.
Việc sử dụng các tín hiệu ở cấp độ dây cho phép các luồng dữ liệu liên tục, làm cho nó tương tự như webhook và WebSockets.
Nó cũng sử dụng giao thức TCP như MQTT. AMQP đặc biệt an toàn vì nó sử dụng giao thức Chất lượng dịch vụ (QoS). Nó cũng đặc biệt thành thạo trong việc xử lý tin nhắn không đồng bộ , bất kể hệ điều hành.
Tuy nhiên, AMQP có một số hạn chế. Đối với người mới bắt đầu, nó không tương thích ngược, vì vậy bạn sẽ chỉ có thể tích hợp với phiên bản hiện tại. Nó cũng phức tạp hơn HTTP. Nó cũng yêu cầu băng thông cao hơn MQTT.
Khi chọn kiểu kiến trúc API cho dự án của mình, tuỳ thuộc vào dự án đó mà bạn sử dụng kiến trúc API cho phù hợp.
Nguồn: ByteByteGo và J. Simpson
