Tuyển dụng
Viettel IDC

JSON-RPC là gì? Cách hoạt động và ứng dụng trong giao tiếp hệ thống

08/01/2026

Trong quá trình xây dựng các hệ thống phần mềm hiện đại, đặc biệt là hệ thống phân tán, microservices và các nền tảng backend phức tạp, nhu cầu giao tiếp giữa các thành phần với nhau ngày càng trở nên quan trọng. Bên cạnh REST API hay SOAP, JSON-RPC là một trong những cơ chế giao tiếp được sử dụng rộng rãi nhờ tính đơn giản, gọn nhẹ và tập trung vào hành vi xử lý. Vậy JSON-RPC là gì, hoạt động ra sao và phù hợp với những bài toán nào trong thực tế? Bài viết dưới đây Viettel IDC sẽ phân tích chi tiết để giúp bạn hiểu rõ nhé.

JSON-RPC là gì?

JSON-RPC là gì?

JSON-RPC là một giao thức Remote Procedure Call (RPC) sử dụng định dạng JSON để truyền dữ liệu giữa client và server. Thay vì thao tác với tài nguyên như REST, JSON-RPC cho phép client gọi trực tiếp các hàm (method) được định nghĩa ở phía server thông qua một request JSON.

Nói cách khác, JSON-RPC giúp client gọi hàm từ xa giống như đang gọi một hàm nội bộ trong chương trình, nhưng thực chất lệnh gọi đó được gửi qua mạng và xử lý ở một hệ thống khác. Kết quả thực thi sẽ được server trả về dưới dạng JSON response. JSON-RPC được thiết kế với mục tiêu đơn giản hóa giao tiếp, không phụ thuộc vào HTTP method (GET, POST, PUT…) và không yêu cầu cấu trúc URL phức tạp. Giao thức này thường được triển khai trên nền HTTP, nhưng về bản chất nó không bị ràng buộc bởi HTTP.

JSON-RPC ra đời trong bối cảnh nào?

JSON-RPC ra đời trong bối cảnh các giao thức RPC truyền thống như XML-RPC và SOAP bộc lộ nhiều hạn chế. XML-RPC sử dụng XML nên khá nặng, khó đọc và tốn tài nguyên xử lý. SOAP còn phức tạp hơn khi yêu cầu chuẩn hóa chặt chẽ về WSDL, schema và cấu trúc message.

Trong khi đó, JSON ngày càng trở nên phổ biến nhờ tính nhẹ, dễ đọc, dễ parse và phù hợp với JavaScript. Các nhà phát triển cần một giao thức RPC đơn giản hơn, không mang theo quá nhiều đặc tả rườm rà, và JSON-RPC xuất hiện để đáp ứng nhu cầu đó. JSON-RPC tập trung vào một mục tiêu cốt lõi là gọi hàm từ xa một cách rõ ràng và trực tiếp, thay vì thiết kế xoay quanh tài nguyên như REST. Điều này đặc biệt phù hợp với các hệ thống nội bộ, backend-to-backend hoặc các nền tảng cần truyền lệnh xử lý phức tạp.

JSON-RPC hoạt động như thế nào?

JSON-RPC hoạt động theo mô hình client- server. Client gửi một request JSON đến server, trong đó chỉ rõ method cần gọi và các tham số liên quan. Server tiếp nhận request, thực thi method tương ứng và trả về kết quả hoặc lỗi.

Quy trình cơ bản bao gồm các bước:

- Client tạo một JSON object chứa thông tin phiên bản, tên method, tham số và ID.

- Request được gửi tới server qua HTTP hoặc một kênh truyền khác.

- Server phân tích request, xác định method và thực thi logic.

- Server trả về response JSON chứa kết quả hoặc thông tin lỗi.

- Client nhận response và xử lý dữ liệu trả về.

JSON-RPC cho phép batch request (gửi nhiều lời gọi trong một request) và notification (gọi hàm không cần response), giúp tối ưu hiệu suất trong một số trường hợp.

Cấu trúc của một JSON-RPC request và response

Trường jsonrpc

Trường jsonrpc dùng để xác định phiên bản giao thức JSON-RPC mà client đang sử dụng, hiện tại phổ biến nhất là giá trị 2.0. Đây không chỉ là một thông tin hình thức mà đóng vai trò quan trọng trong việc đảm bảo server xử lý đúng chuẩn message. Khi hệ thống có nhiều client hoặc nhiều service giao tiếp chéo, việc khai báo rõ phiên bản giúp tránh lỗi không tương thích, đặc biệt trong các hệ thống được nâng cấp dần theo thời gian. Nếu thiếu hoặc sai giá trị jsonrpc, server có thể từ chối request hoặc trả về lỗi định dạng.

Method

method đại diện cho tên hàm từ xa mà client muốn gọi trên server. Khác với REST, nơi endpoint gắn với tài nguyên, JSON-RPC tập trung hoàn toàn vào hành vi xử lý. Điều này khiến method thường được đặt theo logic nghiệp vụ hoặc hành động cụ thể. Ví dụ, thay vì gọi /users/123, client có thể gọi method như getUserDetail hoặc updateUserProfile. Server sẽ ánh xạ method này tới một hàm xử lý cụ thể trong backend. Nếu method không tồn tại hoặc không được phép truy cập, server sẽ trả về lỗi tương ứng trong response.

Params

params là nơi chứa dữ liệu đầu vào cho method, đóng vai trò như tham số khi gọi hàm. JSON-RPC cho phép params ở dạng object (key value) hoặc array, tuy nhiên trong thực tế, dạng object được ưu tiên vì dễ đọc và dễ mở rộng. Việc sử dụng object giúp backend không phụ thuộc vào thứ tự tham số, đồng thời giảm rủi ro lỗi khi thêm hoặc bớt field. Trong các hệ thống phức tạp, params thường được validate kỹ để đảm bảo dữ liệu đầu vào đúng định dạng và không gây lỗi logic.

ID

ID là thành phần giúp liên kết request và response. Khi client gửi request kèm ID, server bắt buộc phải trả về response với cùng ID đó, nhờ vậy client có thể xác định chính xác kết quả của từng lời gọi. Trong trường hợp request không có ID, JSON-RPC coi đó là notification, một dạng lời gọi không yêu cầu phản hồi. Notification thường được dùng cho các tác vụ như ghi log, gửi event hoặc kích hoạt xử lý nền, nơi client không cần chờ kết quả trả về.

Result và Error

Response của JSON-RPC luôn tuân theo nguyên tắc chỉ có một trong hai: result hoặc error. Nếu method được thực thi thành công, server trả về trường result chứa dữ liệu tương ứng. Ngược lại, nếu xảy ra lỗi, response sẽ chứa trường error. Trường error thường bao gồm mã lỗi, thông điệp mô tả và dữ liệu bổ sung để hỗ trợ debug. Cách tách biệt rõ ràng giữa result và error giúp client xử lý logic dễ dàng, không cần kiểm tra trạng thái HTTP như trong REST API.

Cấu trúc của một JSON-RPC request và response

JSON-RPC dùng để làm gì?

JSON-RPC được sử dụng chủ yếu trong các kịch bản giao tiếp backend-to-backend, nơi yêu cầu gọi hàm rõ ràng, ít phụ thuộc vào giao thức HTTP và không cần expose API công khai cho bên thứ ba.

Trong kiến trúc microservices, JSON-RPC giúp các service gọi trực tiếp logic của nhau mà không cần thiết kế nhiều endpoint REST phức tạp. Ngoài ra, JSON-RPC còn xuất hiện phổ biến trong các nền tảng blockchain, hệ thống tài chính, công cụ automation và các API nội bộ yêu cầu hiệu suất cao. Điểm mạnh của JSON-RPC nằm ở việc truyền ý định xử lý thay vì thao tác tài nguyên, rất phù hợp với các hệ thống thiên về nghiệp vụ và logic.

Ưu nhược điểm của JSON-RPC

Về mặt ưu điểm, JSON-RPC có thiết kế đơn giản, dễ triển khai và dễ đọc. Việc sử dụng JSON giúp giảm kích thước payload, tăng tốc độ truyền dữ liệu và tương thích tốt với hầu hết ngôn ngữ lập trình hiện đại.

Tuy nhiên, JSON-RPC cũng tồn tại hạn chế. Do không dựa trên tài nguyên, giao thức này khó tận dụng caching chuẩn của HTTP và không thân thiện với các công cụ RESTful truyền thống. Nếu không kiểm soát chặt chẽ method, hệ thống có thể trở nên khó bảo trì hoặc tiềm ẩn rủi ro bảo mật.

Các vấn đề bảo mật khi sử dụng JSON-RPC

Dù JSON-RPC có thiết kế gọn nhẹ và hiệu quả trong giao tiếp hệ thống, nhưng nếu triển khai thiếu kiểm soát, giao thức này có thể trở thành điểm yếu nghiêm trọng về bảo mật. Nguyên nhân chủ yếu đến từ việc JSON-RPC tập trung vào gọi hàm trực tiếp, trong khi nhiều hệ thống lại không xây dựng lớp bảo vệ tương xứng.

Lộ method và logic backend

Một đặc điểm phổ biến của JSON-RPC là toàn bộ hệ thống thường chỉ sử dụng một endpoint duy nhất, phía sau đó là nhiều method xử lý logic khác nhau. Nếu endpoint này bị public mà không có cơ chế bảo vệ phù hợp, attacker có thể thử nghiệm nhiều giá trị method khác nhau để dò tìm các hàm tồn tại. Khi danh sách method bị lộ, cấu trúc nghiệp vụ và luồng xử lý nội bộ của backend cũng gián tiếp bị phơi bày. Điều này đặc biệt nguy hiểm với các method liên quan đến quản trị, thanh toán hoặc thao tác dữ liệu quan trọng.

Tấn công brute force hoặc abuse request

JSON-RPC không ràng buộc chặt chẽ vào HTTP verb hay tài nguyên, vì vậy việc gửi request hàng loạt trở nên dễ dàng hơn. Kẻ tấn công có thể lợi dụng điều này để brute force tham số, spam gọi method hoặc cố tình tạo tải lớn nhằm làm chậm hoặc sập hệ thống. Trong các hệ thống không giới hạn tần suất request, chỉ cần một endpoint JSON-RPC cũng đủ để trở thành điểm tập trung của các cuộc tấn công từ chối dịch vụ. 

Thiếu xác thực và phân quyền

Một sai lầm phổ biến khi triển khai JSON-RPC là chỉ kiểm tra xác thực ở mức endpoint, mà không kiểm soát quyền truy cập ở từng method cụ thể. Điều này dẫn đến tình trạng người dùng hợp lệ nhưng vẫn có thể gọi các hàm vượt quá phạm vi quyền hạn cho phép. Trong các hệ thống phức tạp, mỗi method JSON-RPC thường tương ứng với một hành động nghiệp vụ riêng biệt. Nếu không có cơ chế phân quyền chi tiết, chỉ cần lộ token hoặc session hợp lệ là attacker có thể thao tác sâu vào hệ thống, gây rủi ro nghiêm trọng về dữ liệu và an toàn vận hành.

Giới hạn rate và kiểm soát truy cập

Để giảm thiểu rủi ro bảo mật, JSON-RPC cần được đặt trong một lớp kiểm soát truy cập nghiêm ngặt. Việc giới hạn số lượng request theo IP, token hoặc user giúp ngăn chặn hiệu quả các hành vi abuse và brute force.

Bên cạnh đó, việc kết hợp JSON-RPC với firewall, WAF hoặc API Gateway cho phép lọc request bất thường, ghi log truy cập và phát hiện sớm các dấu hiệu tấn công. Khi được triển khai đúng cách, các biện pháp này sẽ biến JSON-RPC từ một điểm yếu tiềm ẩn thành một kênh giao tiếp an toàn và ổn định trong hệ thống.

Kết luận

JSON-RPC là một giao thức giao tiếp đơn giản nhưng mạnh mẽ, phù hợp với các hệ thống cần gọi hàm từ xa một cách trực tiếp và linh hoạt. Với cấu trúc gọn nhẹ, dễ triển khai và hiệu quả trong môi trường backend, JSON-RPC vẫn giữ vai trò quan trọng trong nhiều kiến trúc phần mềm hiện đại. Khi được triển khai đúng cách, JSON-RPC sẽ trở thành một công cụ giao tiếp đáng tin cậy cho các hệ thống phức tạp.

Để được hỗ trợ tư vấn và tìm hiểu các dịch vụ của Viettel, bạn có thể liên hệ trực tiếp tới Viettel IDC qua các kênh:

- Hotline: 1800 8088 (miễn phí cước gọi)

- Fanpage: https://www.facebook.com/viettelidc  

Bình luận ()

Đăng nhập | Đăng ký
để gửi bình luận
Ý kiến của bạn sẽ được xét duyệt trước khi đăng.
Ý kiến của bạn sẽ được xét duyệt trước khi đăng.
Ý kiến của bạn sẽ được xét duyệt trước khi đăng.
Xem thêm bình luận

Tin liên quan

15/09/2026

Script là gì? Phân biệt với ngôn ngữ lập trình biên dịch

Script là gì, khác gì với ngôn ngữ lập trình biên dịch? Tìm hiểu các loại script phổ biến, ví dụ minh họa và ưu nhược điểm khi sử dụng.

15/09/2026

Docker Compose là gì? Cấu trúc file và các lệnh cơ bản

Docker Compose là gì, file docker-compose.yml có cấu trúc ra sao? Tìm hiểu các lệnh cơ bản, khác biệt V1/V2 và có nên dùng cho production không.

15/09/2026

Email hosting có hỗ trợ Outlook không? Cách cấu hình chi tiết

Email hosting có dùng được với Outlook không? Xem thông số IMAP/POP3/SMTP cần thiết, cách chọn giao thức phù hợp và trường hợp ngoại lệ cần lưu ý.

15/09/2026

Chi phí sử dụng email hosting có đắt không? Phân tích và ước tính ngân sách

Khám phá mức giá email hosting hiện nay. Phân tích các yếu tố ảnh hưởng đến chi phí và các loại phí ẩn cần lưu ý trước khi đăng ký cho doanh nghiệp.

15/09/2026

Những lưu ý khi chuyển đổi email doanh nghiệp an toàn, hạn chế mất dữ liệu

Hướng dẫn chi tiết các bước chuyển đổi email doanh nghiệp an toàn. Tìm hiểu cách sao lưu, cấu hình bản ghi mạng, thiết lập xác thực và các lỗi cần tránh.

15/09/2026

Khi nào doanh nghiệp nên tự xây dựng Email Server?

Tự xây dựng Email Server tốn chi phí gì, và doanh nghiệp cần đáp ứng điều kiện nào để việc đầu tư này thực sự đáng giá? Có checklist tự đánh giá.

15/09/2026

Email Migration là gì? Các hình thức di chuyển email phổ biến

Email Migration là gì, có những hình thức nào (Cutover, Staged, Hybrid, IMAP)? So sánh chi tiết và tiêu chí giúp chọn đúng hình thức cho doanh nghiệp.

15/09/2026

Email Hosting vs Web Hosting: Phân biệt và có nên dùng chung không?

Khi đăng ký dịch vụ lưu trữ cho website, không ít người dùng nhận thấy nhà cung cấp chào bán kèm cả gói email theo tên miền, khiến ranh giới giữa Email Hosting và Web Hosting trở nên mơ hồ. Liệu email hosting vs web hosting là cùng một dịch vụ hay là hai hệ thống hoàn toàn khác nhau mà chỉ đang được bán chung cho tiện lợi?

15/09/2026

Email Hosting vs Email Server: Nên chọn giải pháp nào cho doanh nghiệp?

So sánh chi tiết Email Hosting và Email Server: ưu nhược điểm, bảng so sánh trực quan và khung ra quyết định giúp doanh nghiệp chọn đúng giải pháp email.

15/09/2026

Có nên sử dụng email hosting giá rẻ? Phân tích ưu nhược điểm và rủi ro

Email hosting giá rẻ có đáng dùng không? Phân tích ưu điểm, rủi ro dùng chung IP, bị đưa vào danh sách đen và tiêu chí giúp quyết định khi nào nên nâng cấp.