Tình hình các giao thức API năm 2023

• Xu hướng các giao thức API cùng ưu/nhược điểm được Postman tổng hợp từ khảo sát với 40.000 nhà phát triển
• Bao gồm REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC, v.v.

REST

• Vẫn là lựa chọn được dùng rộng rãi nhất. Trong 2 năm qua, tỷ lệ này giảm từ 92% xuống 86%
• Tính đơn giản, khả năng mở rộng và dễ tích hợp với dịch vụ web
• Ưu điểm của REST
  • Tính đơn giản và tiêu chuẩn hóa: sử dụng các phương thức HTTP tiêu chuẩn nên các nhà phát triển đã quen với HTTP có thể dễ dàng áp dụng. Sự đơn giản giúp việc học và tích hợp diễn ra nhanh hơn
  • Khả năng mở rộng: đặc tính stateless của REST giúp máy chủ không cần lưu dữ liệu phiên giữa các yêu cầu. Điều này giúp dễ dàng mở rộng theo chiều ngang bằng cách thêm instance mà không cần máy chủ dùng chung
  • Hiệu năng: tính stateless và các phản hồi có thể cache giúp tăng tốc độ thực thi và giảm số lượng yêu cầu
  • Tính mô-đun: dịch vụ RESTful có thể được phát triển thành các thành phần mô-đun. Điều này cho phép cập nhật độc lập và cải thiện khả năng bảo trì
  • Không phụ thuộc nền tảng: có thể dùng với nhiều loại client khác nhau. Khả năng tương tác giúp thúc đẩy việc tích hợp API trên toàn hệ thống
  • Công cụ trưởng thành và hỗ trợ cộng đồng: có nhiều công cụ, thư viện, thực tiễn tốt, hướng dẫn xử lý sự cố và tài nguyên cộng đồng
• Thách thức của REST
  • Over-fetching & under-fetching: client có thể chỉ cần một phần dữ liệu nên dễ xảy ra tình trạng lấy quá nhiều hoặc quá ít dữ liệu. Điều này có thể gây ra vấn đề hiệu năng và lãng phí băng thông
  • Nhiều lần giao tiếp: để truy xuất dữ liệu liên quan có thể cần nhiều request, làm tăng độ trễ. Chuỗi các lần gọi này trở thành vấn đề khi ứng dụng mở rộng
  • Vấn đề quản lý phiên bản: việc tạo phiên bản mới cho REST API có thể phiền phức, đặc biệt khi cấu trúc dữ liệu hoặc chức năng dịch vụ thay đổi. Điều này thường dẫn đến vấn đề tương thích ngược
  • Chi phí stateless: stateless hỗ trợ khả năng mở rộng, nhưng cũng có nghĩa là mọi request phải cung cấp toàn bộ ngữ cảnh cần thiết. Điều này có thể tạo thêm overhead, nhất là khi client phải gửi nhiều dữ liệu lặp lại
  • Thiếu khả năng thời gian thực: REST không tối ưu cho các ứng dụng thời gian thực như chat hay live feed. WebSocket và SSE phù hợp hơn cho các trường hợp này

WebHooks

• Webhook là callback HTTP tùy chỉnh được kích hoạt bởi một sự kiện trong ứng dụng nguồn
• Khi sự kiện xảy ra, ứng dụng nguồn gửi một request HTTP (thường là POST) đến URI do ứng dụng đích chỉ định, cho phép giao tiếp gần thời gian thực theo hướng sự kiện mà không cần polling lặp lại
• Webhook ngày càng phổ biến, với 36% nhà phát triển sử dụng để tích hợp trơn tru giữa nhiều hệ thống
• Ưu điểm của WebHooks
  • Giao tiếp thời gian thực: webhook cho phép truyền dữ liệu theo thời gian thực. Khi sự kiện xảy ra, dữ liệu tương ứng được gửi đi để đảm bảo đồng bộ mới nhất giữa các hệ thống
  • Hiệu quả: webhook loại bỏ polling tốn tài nguyên, giúp tiết kiệm năng lực tính toán và băng thông
  • Tính linh hoạt: webhook có thể được cấu hình để phản hồi với các sự kiện cụ thể, cho phép tùy chỉnh hành động hoặc trigger nào trong một ứng dụng sẽ gửi dữ liệu sang ứng dụng khác
  • Tích hợp đơn giản hơn: nhờ sử dụng các phương thức HTTP nên có thể dễ dàng dùng trong hầu hết ứng dụng
  • Hỗ trợ kiến trúc tách rời: webhook hoạt động dựa trên sự kiện nên tự nhiên hỗ trợ kiến trúc hướng sự kiện hoặc tách rời, qua đó cải thiện tính mô-đun và khả năng mở rộng
• Thách thức của WebHooks
  • Xử lý lỗi: nếu phía nhận webhook bị down hoặc xảy ra lỗi khi xử lý callback thì có nguy cơ mất dữ liệu. Hệ thống dùng webhook cần có cơ chế xử lý lỗi mạnh mẽ bao gồm retry hoặc log
  • Vấn đề bảo mật: webhook truyền dữ liệu qua Internet nên dễ bị chặn bắt hoặc tấn công ác ý. Các biện pháp bảo mật API như HTTPS và ký payload là bắt buộc
  • Quản lý nhiều webhook: việc quản lý và giám sát webhook có thể phức tạp, đặc biệt khi ứng dụng phát triển và bắt đầu phụ thuộc vào nhiều webhook. Cần theo dõi cẩn thận để đảm bảo mọi webhook hoạt động đúng và quản lý các endpoint khác nhau
  • Khả năng quá tải: số lượng lớn callback đồng thời có thể gây áp lực lên phía nhận của ứng dụng, nhưng rate limiting hoặc batch processing có thể giúp xử lý các đợt tăng đột biến

GraphQL

• GraphQL là một ngôn ngữ truy vấn cho API, đồng thời là runtime phía máy chủ để thực thi truy vấn bằng hệ thống kiểu được định nghĩa cho dữ liệu
• Được Facebook phát triển năm 2012 và phát hành dưới dạng dự án mã nguồn mở vào năm 2015, GraphQL mang đến một lựa chọn thay thế linh hoạt và hiệu quả hơn cho REST API truyền thống
• Tỷ lệ chấp nhận GraphQL đang tăng lên 29% trong giới phát triển, cho thấy tầm quan trọng của nó trong bối cảnh API hiện nay
• Khác với REST, nơi phải đi qua nhiều API endpoint để lấy dữ liệu liên quan, GraphQL cho phép lấy toàn bộ dữ liệu cần thiết chỉ trong một truy vấn
• Điều này đặc biệt hữu ích với lập trình viên frontend vì nó mang lại nhiều quyền kiểm soát hơn đối với quá trình truy xuất dữ liệu và giúp tạo ra giao diện người dùng năng động, phản hồi tốt hơn
• Ưu điểm của GraphQL
  • Schema kiểu mạnh: GraphQL API có schema kiểu mạnh, vì vậy nhà phát triển biết chính xác dữ liệu và kiểu nào có thể dùng trong truy vấn
  • Truy xuất dữ liệu chính xác: client có thể yêu cầu đúng dữ liệu mình cần, giải quyết vấn đề over-fetching và under-fetching, từ đó cải thiện hiệu năng và tiết kiệm chi phí
  • Độ phức tạp truy vấn và nhiều tài nguyên: GraphQL hỗ trợ truy vấn nhiều kiểu dữ liệu trong một request, giúp giảm số lượng request mạng đối với dữ liệu phức tạp và có liên hệ với nhau
  • Cập nhật thời gian thực qua subscription: GraphQL hỗ trợ đồng bộ thời gian thực thông qua subscription, cho phép client được cập nhật theo thời gian thực
  • Introspection: schema tự mô tả của GraphQL giúp việc phát triển trở nên dễ dàng hơn thông qua tự kiểm tra
• Thách thức của GraphQL
  • Độ phức tạp truy vấn: sự linh hoạt mà GraphQL mang lại cho client cũng có mặt trái. Các truy vấn quá phức tạp hoặc lồng nhau sâu có thể ảnh hưởng xấu đến hiệu năng
  • Đường cong học tập: GraphQL có đường cong học tập dốc hơn REST do có các khái niệm mới như mutation và subscription
  • Quản lý phiên bản: tính linh hoạt của truy vấn khiến việc thay đổi schema có thể làm hỏng truy vấn hiện có và khiến versioning trở nên phức tạp
  • Khả năng sử dụng tài nguyên quá mức: client có thể yêu cầu nhiều tài nguyên trong một truy vấn, dẫn đến nguy cơ lấy nhiều dữ liệu hơn cần thiết và gây quá tải máy chủ
  • Vấn đề bảo mật: kẻ xấu có thể lợi dụng tính linh hoạt của GraphQL để dùng các truy vấn phức tạp làm quá tải máy chủ

SOAP

• SOAP(Simple Object Access Protocol) là một giao thức để trao đổi thông tin có cấu trúc nhằm triển khai web service
• Sử dụng XML làm định dạng thông điệp và thường dùng HTTP hoặc SMTP cho lớp đàm phán và truyền thông điệp
• Khác với REST và GraphQL, SOAP có các tiêu chuẩn nghiêm ngặt và các tính năng tích hợp sẵn như giao dịch tương thích ACID, bảo mật và mẫu truyền thông điệp
• Dù mức sử dụng đã giảm xuống chỉ còn 26% nhà phát triển, SOAP vẫn là một lựa chọn đáng tin cậy cho một số ứng dụng nhất định
• Ưu điểm của SOAP
  • Typing mạnh và hợp đồng rõ ràng: có kiểu dữ liệu mạnh và hợp đồng chặt chẽ được định nghĩa trong tài liệu WDSL(Web Services Description Language)
  • Tính năng bảo mật tích hợp: SOAP cung cấp bảo mật toàn diện thông qua xác thực, phân quyền và mã hóa được triển khai theo tiêu chuẩn WS-Security. Vì vậy đây là lựa chọn được ưa chuộng cho các ứng dụng doanh nghiệp
  • Giao dịch ACID: SOAP hỗ trợ các giao dịch ACID, rất cần thiết cho các ứng dụng mà tính toàn vẹn dữ liệu là yếu tố quan trọng như hệ thống tài chính hoặc y tế
  • Truyền thông điệp đáng tin cậy: SOAP đảm bảo việc chuyển phát thông điệp đáng tin cậy và xử lý lỗi tốt, nên rất phù hợp cho các hệ thống cần đảm bảo chuyển phát thông điệp
  • Trung lập về ngôn ngữ, nền tảng và phương thức truyền: giống như REST, dịch vụ SOAP có thể được sử dụng bởi bất kỳ client nào hiểu XML, bất kể ngôn ngữ lập trình, nền tảng hay giao thức truyền tải bên dưới
• Thách thức của SOAP
  • Độ phức tạp và đường cong học tập: SOAP có thể phức tạp hơn trong triển khai do các tiêu chuẩn chặt chẽ và việc sử dụng XML, nên đường cong học tập dốc hơn các lựa chọn như REST hoặc GraphQL
  • Thông điệp dài dòng: header của thông điệp SOAP mang theo nhiều overhead, khiến payload lớn hơn JSON của REST và GraphQL. Điều này có thể ảnh hưởng đến hiệu năng và mức sử dụng băng thông
  • Hỗ trợ cộng đồng hạn chế: SOAP đang dần mất vị thế, điều đó đồng nghĩa hỗ trợ từ cộng đồng và các thư viện sẵn có cũng đang giảm
  • Kém linh hoạt hơn: khi hợp đồng thay đổi, cả client lẫn server đều có thể phải cập nhật phần triển khai tương ứng, đây có thể là một nhược điểm
  • Vấn đề tường lửa: SOAP có thể sử dụng các giao thức truyền tải khác ngoài HTTP/HTTPS, điều này có nghĩa là có thể gặp phải hạn chế từ tường lửa. Vì vậy SOAP kém đa dụng hơn trong một số môi trường triển khai

WebSocket

• WebSocket cung cấp kết nối hai chiều liên tục, độ trễ thấp giữa client và server, cho phép truyền dữ liệu thời gian thực
• Khác với chu kỳ request-response của HTTP, WebSocket cho phép server gửi dữ liệu đến client bất cứ lúc nào sau bắt tay ban đầu
• Giúp dễ dàng cập nhật dữ liệu tức thời cho các ứng dụng chat, game online, nền tảng giao dịch, v.v.
• Theo khảo sát, 25% nhà phát triển đang sử dụng WebSocket
• Ưu điểm của WebSocket
  • Giao tiếp hai chiều thời gian thực: giao tiếp hai chiều thời gian thực có độ trễ thấp hơn kết nối HTTP vốn phải thiết lập lại sau mỗi lần trao đổi
  • Giảm chi phí gián tiếp: sau bắt tay ban đầu, kết nối vẫn được giữ mở nên giảm overhead từ header vốn đi kèm các request HTTP truyền thống
  • Sử dụng tài nguyên hiệu quả: kết nối lâu dài dùng tài nguyên máy chủ hiệu quả hơn so với long polling
• Thách thức của WebSocket
  • Độ phức tạp triển khai: triển khai WebSocket có thể phức tạp và tốn thời gian hơn các kiến trúc API khác, đặc biệt khi phải cân nhắc phương án thay thế trong môi trường không hỗ trợ WebSocket
  • Thiếu tính năng tích hợp sẵn: khác với SOAP có sẵn các tính năng cho bảo mật và giao dịch, WebSocket gần với mức cơ bản hơn nên nhà phát triển phải tự triển khai các tính năng này
  • Tiêu thụ tài nguyên: kết nối WebSocket mở thường hiệu quả hơn long polling, nhưng vẫn tiêu tốn tài nguyên máy chủ và có thể trở thành vấn đề ở quy mô lớn
  • Hạn chế mạng: một số proxy và tường lửa không hỗ trợ WebSocket, có thể gây ra vấn đề kết nối trong một số môi trường mạng nhất định

gRPC

• gRPC, viết tắt của "Google Remote Procedure Call", là một giao thức hiện đại hiệu năng cao giúp việc giao tiếp giữa các dịch vụ trở nên dễ dàng hơn
• Được xây dựng trên HTTP/2 và tận dụng protocol buffers để định nghĩa các phương thức dịch vụ và định dạng thông điệp
• Khác với REST API dùng các động từ HTTP tiêu chuẩn như GET và POST, gRPC hỗ trợ dịch vụ phơi bày các phương thức tùy chỉnh tương tự chức năng trong ngôn ngữ lập trình
• Ưu điểm của gRPC
  • Hiệu năng: nhờ dùng HTTP/2 và protocol buffers, gRPC có thể đạt độ trễ thấp và thông lượng cao
  • Typing mạnh: giống SOAP và GraphQL, gRPC có kiểu mạnh. Nhờ đó kiểu dữ liệu được kiểm tra ở thời điểm biên dịch, giúp giảm lỗi
  • Hỗ trợ đa ngôn ngữ: gRPC hỗ trợ rất tốt nhiều ngôn ngữ lập trình như Go, Java, C# và Node.js
  • Streaming: gRPC có thể xử lý ngay các request và response dạng streaming, phù hợp cho các trường hợp sử dụng phức tạp như kết nối dài hạn và cập nhật thời gian thực
  • Đi kèm đầy đủ tính năng: gRPC hỗ trợ trực tiếp các tính năng quan trọng như cân bằng tải, retry và timeout
• Thách thức của gRPC
  • Hỗ trợ trình duyệt: hỗ trợ gRPC nguyên bản trong trình duyệt vẫn còn hạn chế, nên không phù hợp cho giao tiếp trực tiếp client-server trong ứng dụng web
  • Đường cong học tập: nhà phát triển cần học cách sử dụng protocol buffers, định nghĩa dịch vụ tùy chỉnh và các tính năng khác của gRPC, điều này có thể làm giảm năng suất ban đầu
  • Độ phức tạp khi debug: protocol buffers không dễ đọc với con người, nên việc debug và kiểm thử gRPC API khó hơn so với JSON API

Các giao thức API khác

• MQTT : giao thức nhắn tin nhẹ được tối ưu cho mạng băng thông thấp như IoT. Client có thể publish và subscribe thông điệp qua broker, nhưng thiếu một số tính năng về bảo mật và khả năng mở rộng
• AMQP : tiêu chuẩn nhắn tin doanh nghiệp mạnh mẽ hơn, đảm bảo chuyển phát thông điệp đáng tin cậy và định tuyến thông điệp linh hoạt. Tuy nhiên, nó có thể phức tạp hơn và có nhiều overhead hơn so với các giao thức nhẹ
• SSE : cho phép giao tiếp một chiều từ server đến client qua HTTP, phù hợp cho cập nhật thời gian thực nhưng thiếu khả năng hai chiều
• EDI : tự động hóa giao tiếp B2B bằng cách chuẩn hóa các tài liệu điện tử như đơn đặt hàng và hóa đơn, nhưng chi phí ban đầu cao và cũng đòi hỏi hạ tầng phức tạp
• EDA : thúc đẩy kiến trúc hướng sự kiện, trong đó các thành phần phản ứng với sự kiện, cho phép hệ thống thời gian thực có khả năng mở rộng nhưng việc debug phức tạp

Kết luận

• Bối cảnh API vẫn đang tiếp tục phát triển khi các nhà phát triển áp dụng các kiến trúc, giao thức và công cụ mới
• REST vẫn chiếm ưu thế nhờ tính đơn giản và mức độ phổ biến, nhưng các lựa chọn thay thế như GraphQL và gRPC đang thu hút sự quan tâm vì giải quyết được các điểm yếu như over-fetching và giao diện quá nhiều lời gọi
• Đồng thời, các nhà phát triển cũng ngày càng coi trọng WebHooks và WebSocket do nhu cầu giao tiếp thời gian thực
• Trong nhiều trường hợp sử dụng API phổ biến, REST vẫn là cách tiếp cận mặc định vững chắc nhờ khả năng mở rộng, khả năng tương tác và mức độ dễ áp dụng. Nó cũng được hưởng lợi từ sự trưởng thành của cộng đồng
• Tuy vậy, mọi giao thức đều có ưu và nhược điểm, và khi ứng dụng ngày càng phức tạp hơn, các nhà phát triển đang mở rộng bộ công cụ giao thức API một cách khôn ngoan để bao gồm cả các giải pháp chuyên biệt như GraphQL và gRPC
• Thay vì tìm một giải pháp chung áp dụng cho mọi trường hợp, điều tốt nhất với nhà phát triển API là hiểu rõ điểm mạnh và điểm yếu của nhiều giao thức khác nhau
• Bằng cách thiết kế các hệ thống kết hợp REST, WebHook, WebSocket, GraphQL và các cách tiếp cận khác với ưu điểm riêng, nhà phát triển có thể xây dựng các API mạnh mẽ, hiệu quả và dễ bảo trì
• Mức độ phổ biến của từng giao thức riêng lẻ sẽ còn tiếp tục biến động, nhưng xu hướng quan trọng nhất trong bối cảnh API là sự đa dạng ngày càng tăng
• Nhà phát triển cần đón nhận triết lý đa giao thức này để tạo ra giải pháp API tối ưu

[zerocyber]

Xem hay quá ạ

[test191919]

Nếu không phải là công việc chỉ kết thúc bằng một hành động đơn lẻ, mang tính một lần rồi thôi, thì transaction chẳng phải là thứ bắt buộc sao? (Dù là bắt buộc mà đến giờ mới hướng tới REST thì đúng là mỉa mai, điểm này thì mình cũng đồng cảm haha)