Tổng hợp: REST, SOAP, gRPC, WebRPC, Webhook và WebSocket#

1. Bức tranh tổng thể#

REST, SOAP, gRPC, WebRPC, Webhook và WebSocket phản ánh quá trình phát triển của giao tiếp phần mềm: từ trao đổi message có cấu trúc, thiết kế API và thông báo sự kiện đến kết nối realtime và gọi hàm hiệu năng cao.

REST, SOAP, gRPC, WebRPC, Webhook và WebSocket không hoàn toàn thay thế lẫn nhau vì chúng giải quyết các lớp giao tiếp khác nhau:

• REST là một architectural style cho API dựa trên tài nguyên và HTTP, không phải một protocol cụ thể.
• SOAP là protocol trao đổi message có cấu trúc, thường dùng XML và hợp đồng WSDL.
• gRPC và WebRPC áp dụng mô hình RPC, trong đó client yêu cầu server thực hiện một hàm hoặc phương thức; WebRPC không có một tiêu chuẩn hay ngày phát minh chung vì tên này được nhiều dự án độc lập sử dụng.
• Webhook là pattern/cơ chế tích hợp theo sự kiện, thường để một server chủ động gọi server khác; nó không phải protocol được chuẩn hóa như WebSocket.
• WebSocket duy trì kết nối dài hạn và hai chiều để client và server trao đổi dữ liệu realtime.
• SSE là cơ chế liên quan dùng để server liên tục đẩy dữ liệu một chiều tới browser.
• FCM, APNs và Web Push dùng để gửi thông báo khi ứng dụng hoặc browser không mở hay không duy trì kết nối.

1.1. Hình ảnh dễ nhớ#

Có thể nhớ bằng ví dụ đơn giản:

1.2. So sánh vai trò và cách kết nối#

Điểm quan trọng:

• Webhook và WebSocket không trực tiếp thay thế REST/gRPC.
• Một hệ thống có thể dùng REST để tải dữ liệu ban đầu và WebSocket để cập nhật realtime.
• Một hệ thống có thể nhận webhook từ bên ngoài rồi gọi gRPC vào microservice nội bộ.
• SOAP thường tồn tại tại biên tích hợp với hệ thống doanh nghiệp cũ.

2. Tóm lược từng loại#

2.1. Webhook#

Khái niệm#

Webhook là cơ chế một hệ thống chủ động gửi thông báo đến một URL của hệ thống khác khi có sự kiện xảy ra.

Ví dụ:

Khách hàng thanh toán thành công
        ↓
Hệ thống thanh toán gửi HTTP POST
        ↓
Backend cửa hàng nhận webhook

Trường hợp sử dụng#

• Thanh toán thành công.
• Có đơn hàng mới.
• GitHub có commit hoặc pull request mới.
• Một pipeline hoàn thành.
• Một dịch vụ bên ngoài thay đổi trạng thái.
• Hệ thống máy A, B, C báo trạng thái về backend trung tâm.

Đặc điểm#

• Chủ yếu dùng cho giao tiếp server-to-server.
• Không cần giữ kết nối liên tục.
• Chỉ gửi khi có sự kiện.
• Thường dùng HTTP POST.
• Cần xử lý retry, xác thực chữ ký, idempotency và chống gửi trùng.

Tối ưu payload cho Webhook#

Webhook nên gửi payload sự kiện tối thiểu, chẳng hạn loại sự kiện, mã tài nguyên và phần dữ liệu thay đổi. Khi cần dữ liệu đầy đủ, hệ thống nhận có thể dùng ID trong webhook để gọi REST hoặc gRPC lấy chi tiết. Cách này tránh gửi lặp lại toàn bộ object trong mỗi sự kiện.

Quan hệ giữa Webhook và trình duyệt#

Browser thông thường không trực tiếp nhận webhook.

Kiến trúc đúng thường là:

Máy A ──Webhook──┐
Máy B ──Webhook──┼──► Backend
Máy C ──Webhook──┘       │
                         └──WebSocket/SSE──► Browser

Webhook nhận trạng thái từ nhiều hệ thống vào backend. Sau đó backend cập nhật trình duyệt bằng WebSocket hoặc SSE.

2.2. WebSocket#

Khái niệm#

WebSocket tạo một kết nối lâu dài giữa client và server. Sau khi kết nối được mở, hai bên có thể gửi dữ liệu cho nhau bất cứ lúc nào.

Ví dụ:

Browser ◄──────── WebSocket ────────► Server

Trường hợp sử dụng#

• Chat trực tiếp.
• Game online.
• Dashboard trạng thái máy.
• Giá cổ phiếu hoặc tiền mã hóa cập nhật liên tục.
• Theo dõi vị trí.
• Theo dõi tiến trình xử lý.
• Cộng tác realtime.
• Điều khiển hoặc giám sát thiết bị.

Đặc điểm#

• Hai chiều.
• Kết nối tồn tại lâu.
• Server có thể chủ động gửi dữ liệu.
• Phù hợp với dữ liệu realtime.
• Có thể phục vụ đồng thời nhiều browser, app native và thiết bị.

Tối ưu payload cho WebSocket#

• Dùng binary frame với Protocol Buffers, MessagePack hoặc CBOR khi JSON text quá lớn.
• Chỉ gửi phần trạng thái thay đổi thay vì gửi lại toàn bộ object.
• Có thể gộp nhiều message nhỏ thành một message nếu độ trễ cho phép.

Phạm vi kết nối của WebSocket#

WebSocket không chỉ dùng để trao đổi liên tục với một máy hoặc một client.

Tiêu chí chính là:

Client và server cần giữ kết nối mở để trao đổi thường xuyên hoặc server cần chủ động đẩy dữ liệu.

Một server có thể kết nối với nhiều client:

┌── Browser A
WebSocket Server ───┼── Browser B
                    ├── Native App C
                    └── Thiết bị D

2.3. REST API#

Khái niệm#

REST là một phong cách thiết kế API dựa trên tài nguyên và các phương thức HTTP.

Ví dụ:

GET /machines
GET /machines/12
POST /orders
PUT /users/20
DELETE /files/30

REST thường trả dữ liệu JSON:

{
  "name": "Machine A",
  "status": "running"
}

Trường hợp sử dụng#

• CRUD thông thường.
• Browser gọi backend.
• Mobile app gọi backend.
• Public API.
• API cho đối tác.
• Dữ liệu có thể cache.
• Hệ thống cần dễ kiểm tra bằng trình duyệt, curl hoặc Postman.

Ưu điểm#

• Dễ hiểu.
• Dễ debug.
• Được browser và hạ tầng HTTP hỗ trợ tốt.
• Phù hợp CDN, cache và reverse proxy.
• Không bắt buộc code generation.
• Dễ cung cấp cho đối tác bên ngoài.

Điểm yếu#

• JSON có thể dài hơn định dạng nhị phân.
• Không có schema chặt nếu không bổ sung OpenAPI/JSON Schema.
• Streaming và realtime không phải thế mạnh tự nhiên.
• Một API REST thiết kế kém có thể tạo nhiều request nhỏ hoặc trả quá nhiều dữ liệu.

Tối ưu payload và điểm cần lưu ý#

REST không mặc nhiên “nhẹ”. Payload vẫn có thể rất lớn nếu trả quá nhiều trường, không phân trang, không nén hoặc lặp lại dữ liệu không thay đổi.

Các cách tối ưu thường dùng:

• Chỉ trả các trường client thực sự cần.
• Dùng pagination cho danh sách lớn.
• Gộp nhiều thao tác nhỏ bằng batch endpoint khi phù hợp.
• Nén JSON bằng gzip hoặc Brotli qua HTTP.
• Dùng cache, ETag hoặc Last-Modified để tránh truyền lại dữ liệu không đổi.
• Có thể dùng MessagePack hoặc CBOR thay JSON nếu client và server cùng hỗ trợ.

2.4. SOAP API#

Khái niệm#

SOAP là một giao thức trao đổi message có cấu trúc, thường dùng XML.

Ví dụ:

<soap:Envelope>
    <soap:Body>
        <DatMon>
            <TenMon>Pizza</TenMon>
            <SoLuong>2</SoLuong>
        </DatMon>
    </soap:Body>
</soap:Envelope>

Trường hợp sử dụng#

• Hệ thống ngân hàng hoặc bảo hiểm cũ.
• Hệ thống doanh nghiệp truyền thống.
• Đối tác yêu cầu WSDL.
• Hệ thống cần hợp đồng message rất chặt.
• Môi trường đã sử dụng hệ sinh thái WS-*.
• Tích hợp lâu đời với middleware doanh nghiệp.

Ưu điểm#

• Hợp đồng dữ liệu chặt.
• XML Schema và WSDL rõ ràng.
• Hệ sinh thái tiêu chuẩn doanh nghiệp lớn.
• Có các chuẩn liên quan đến security, addressing và transaction.

Điểm yếu#

• XML dài và nặng.
• Khó đọc hơn JSON.
• Công cụ và cấu hình phức tạp.
• Không phù hợp cho nhiều API web đơn giản hiện đại.

Tối ưu payload cho SOAP#

Do XML thường dài, SOAP có thể giảm lưu lượng bằng nén gzip ở tầng HTTP/transport và không gửi các phần tử tùy chọn không cần thiết. Tuy nhiên, payload thường vẫn lớn hơn các định dạng nhị phân như Protocol Buffers.

Tiêu chí lựa chọn SOAP#

SOAP không được lựa chọn chỉ vì dữ liệu quan trọng hoặc có tần suất thấp.

Mức độ quan trọng không quyết định REST hay SOAP.

Một REST API hoặc gRPC API vẫn có thể xử lý giao dịch rất quan trọng nếu có:

• TLS.
• Authentication.
• Authorization.
• Chữ ký request.
• Idempotency.
• Audit log.
• Transaction.
• Retry phù hợp.

SOAP thường được chọn vì hợp đồng, tiêu chuẩn doanh nghiệp hoặc hệ thống cũ, không phải vì request ít hay quan trọng hơn.

2.5. gRPC#

gRPC là framework RPC do Google phát triển, cho phép client gọi phương thức trên server gần giống gọi một hàm cục bộ. API được định nghĩa bằng file .proto; công cụ sau đó sinh mã client/server cho nhiều ngôn ngữ.

service Calculator {
    rpc Add(AddRequest) returns (AddResponse);
}

gRPC thường sử dụng:

• Protocol Buffers để mã hóa dữ liệu nhị phân nhỏ gọn.
• HTTP/2 để tái sử dụng kết nối và chạy nhiều luồng song song.
• Code generation để tạo client SDK và bảo đảm kiểu dữ liệu.
• Unary và streaming RPC, gồm server streaming, client streaming và truyền hai chiều.

Khi phù hợp#

gRPC đặc biệt phù hợp cho:

• Giao tiếp giữa microservice hoặc backend nội bộ.
• Native app và backend do cùng một tổ chức kiểm soát.
• Hệ thống có nhiều request nhỏ hoặc dữ liệu truyền liên tục.
• Trường hợp cần payload nhỏ, schema chặt, streaming và SDK tự sinh.

Điểm mạnh và giới hạn#

Protocol Buffers, streaming và việc tái sử dụng kết nối HTTP/2 đã là các cơ chế tối ưu lưu lượng quan trọng của gRPC. Message vẫn nên được thiết kế gọn, tránh trả các field không cần thiết và tránh chia một thao tác thành quá nhiều RPC nhỏ.

Hiệu năng thực tế vẫn phụ thuộc vào ngôn ngữ, kích thước message, cách tái sử dụng kết nối, proxy, database và business logic. Vì vậy, gRPC thường là lựa chọn mạnh cho backend-to-backend và native app, nhưng không phải lựa chọn tối ưu cho mọi API.

2.6. WebRPC#

Khái niệm#

WebRPC không phải tên của một tiêu chuẩn duy nhất được dùng thống nhất trong toàn ngành.

Tên này có thể chỉ các thư viện hoặc framework khác nhau đưa mô hình RPC vào ứng dụng web.

Một số implementation cho phép:

• Định nghĩa schema.
• Sinh client và server code.
• Gọi phương thức theo kiểu RPC.
• Truyền dữ liệu qua HTTP.
• Dùng JSON hoặc định dạng riêng.

Ví dụ ý tưởng:

getUser(10)

thay vì:

GET /users/10

Vai trò#

WebRPC nằm cùng nhóm với REST, SOAP và gRPC:

Các kiểu API
├── REST
├── SOAP
├── gRPC
└── WebRPC

Quan hệ giữa WebRPC và tối ưu payload#

WebRPC không phải lớp dùng để tự động tối ưu payload cho REST, SOAP, WebSocket và Webhook.

Không nên hiểu:

REST + WebRPC = REST nhẹ hơn
WebSocket + WebRPC = WebSocket nhẹ hơn
SOAP + WebRPC = SOAP nhẹ hơn

WebRPC là một cách thiết kế/gọi API. Payload có nhỏ hay không phụ thuộc implementation và định dạng dữ liệu. Nếu implementation dùng JSON thì có thể áp dụng gzip/Brotli và chỉ trả các trường cần thiết; nếu hỗ trợ định dạng nhị phân thì payload có thể nhỏ hơn, nhưng điều này không phải đặc tính chung của mọi WebRPC.

3. Sử dụng trong thực tế#

3.1. Trình duyệt web#

REST#

Phù hợp nhất cho:

• Tải danh sách.
• Xem chi tiết.
• Tạo, sửa, xóa dữ liệu.
• Public API.
• API có cache.

Browser ──REST──► Backend

WebSocket#

Phù hợp cho:

• Realtime hai chiều.
• Chat.
• Dashboard trạng thái máy.
• Game.
• Điều khiển trực tiếp.

Browser ◄──WebSocket──► Backend

SSE#

Phù hợp khi server chỉ cần đẩy dữ liệu một chiều:

Backend ──SSE──► Browser

Ví dụ:

• Log realtime.
• Tiến trình xử lý.
• Feed sự kiện.
• Trạng thái chỉ đọc.

Webhook#

Webhook không thường gửi trực tiếp tới browser.

External Service ──Webhook──► Backend
Backend ──WebSocket/SSE──► Browser

SOAP#

Dùng khi browser/backend cần tích hợp với hệ thống doanh nghiệp yêu cầu SOAP. Thông thường browser không trực tiếp xử lý SOAP phức tạp; backend làm lớp trung gian.

gRPC#

Browser thường phải dùng gRPC-Web và proxy. gRPC native phù hợp với backend hoặc app native hơn.

WebRPC#

Có thể phù hợp nếu framework hỗ trợ browser tốt, tạo client typed và phù hợp với hệ sinh thái dự án.

Ưu điểm chung của web browser#

• Không cần cài ứng dụng.
• Cập nhật tập trung tại server.
• Dễ phân phối.
• Chạy trên nhiều hệ điều hành.
• Dễ mở rộng số lượng người dùng ở phía client.

Nhưng browser có giới hạn:

• Sandbox.
• Hạn chế network API.
• Không duy trì kết nối khi tab bị đóng.
• Background execution bị giới hạn.
• Không trực tiếp nhận webhook như server.
• gRPC native bị hạn chế.

3.2. Ứng dụng native#

Khi gRPC rất phù hợp#

gRPC thường là một trong những lựa chọn tốt nhất nếu:

• Kiểm soát cả app và backend.
• App và backend cùng dùng .proto.
• Cần payload nhỏ.
• Cần hiệu năng.
• Có nhiều request nhỏ.
• Cần streaming.
• Muốn sinh SDK tự động.
• Có nhiều nền tảng client nhưng cùng contract.

Native App
    │
    ├── gRPC unary ───────► Request/response
    ├── gRPC streaming ───► Dữ liệu liên tục
    └── Protobuf ─────────► Payload nhị phân

Khi REST vẫn tốt hơn#

REST có thể hợp lý hơn nếu:

• API chỉ là CRUD đơn giản.
• API được công khai cho đối tác.
• Cần debug nhanh.
• Cần CDN/cache.
• Backend đã có REST ổn định.
• Không muốn quản lý code generation.
• Client không cần streaming.

Realtime trong native app#

Khi app đang mở:

• gRPC streaming.
• WebSocket.

Khi app đang background hoặc bị đóng:

• Android: FCM.
• iOS: APNs.
• Sau khi người dùng mở app, dùng REST hoặc gRPC để đồng bộ dữ liệu thật.

Server ──FCM/APNs──► Native App
Native App ──REST/gRPC──► Backend để lấy dữ liệu chi tiết

Kết luận#

Không nên nói:

Native app thì gRPC luôn tốt nhất.

Nên nói:

gRPC thường là lựa chọn rất mạnh cho native app khi kiểm soát cả client và backend, cần schema chặt, payload nhỏ, streaming và hiệu năng cao.

3.3. Kiến trúc kết hợp#

Một hệ thống thực tế có thể dùng đồng thời nhiều công nghệ:

Browser ──REST──► API Gateway
Browser ◄─WebSocket/SSE─► Realtime Service

External Payment
        └──Webhook──► Webhook Receiver

API Gateway
        └──gRPC──► Internal Services

Legacy Bank
        └──SOAP──► Integration Service

Ví dụ hệ thống giám sát nhiều máy#

Máy A ──Webhook/REST──┐
Máy B ──Webhook/REST──┼──► Backend trạng thái
Máy C ──Webhook/REST──┘          │
                                 ├── Database
                                 └── WebSocket/SSE ──► Browser Dashboard

Nếu máy cần truyền dữ liệu liên tục:

Máy A ◄──WebSocket/gRPC stream──► Backend
Máy B ◄──WebSocket/gRPC stream──► Backend
Máy C ◄──WebSocket/gRPC stream──► Backend

Nếu chỉ báo sự kiện thỉnh thoảng:

Máy A ──Webhook──► Backend

3.4. Lựa chọn nhanh theo nhu cầu#

4. Kết luận#

Không có công nghệ nào tốt nhất cho mọi trường hợp.

Kiến trúc thường tối ưu khi kết hợp:

Browser
├── REST cho dữ liệu thông thường
└── WebSocket/SSE cho realtime

Backend
├── gRPC giữa các microservice
├── Webhook để nhận sự kiện bên ngoài
└── SOAP khi tích hợp hệ thống cũ

Native App
├── REST hoặc gRPC khi app đang hoạt động
├── WebSocket/gRPC streaming nếu cần realtime
└── FCM/APNs khi app background hoặc đã đóng

Nhận định cuối cùng:

gRPC thường là một trong những lựa chọn mạnh nhất cho backend nội bộ và native app khi kiểm soát cả hai đầu, nhưng REST, WebSocket, Webhook và SOAP vẫn có các vai trò riêng mà gRPC không thay thế hoàn toàn.