JSON-RPC là gì? Tin nhắn, Phương thức và Xử lý Lỗi

JSON-RPC là gì?

JSON-RPC là một giao thức gọi thủ tục từ xa nhẹ, không trạng thái, đại diện cho các cuộc gọi phương thức, kết quả và lỗi dưới dạng các đối tượng JSON. Phiên bản 2.0 định nghĩa các thành viên tin nhắn và quy tắc xử lý nhưng không yêu cầu HTTP hoặc bất kỳ phương tiện cụ thể nào khác. Một khách hàng đặt tên một phương thức, tùy chọn cung cấp các tham số có cấu trúc, và sử dụng một id để liên kết một phản hồi với yêu cầu của mình.

Định nghĩa hữu ích bao gồm cả cơ chế và ranh giới của nó. JSON-RPC ảnh hưởng đến một phần cụ thể của một trao đổi, trong khi các trách nhiệm lân cận vẫn thuộc về HTTP, trình duyệt, phương tiện được chọn, ứng dụng, hoặc mô hình dữ liệu của máy chủ. Giữ các lớp đó tách biệt giúp các báo cáo lỗi có thể tái sản xuất và ngăn chặn một thay đổi cấu hình bị nhầm lẫn với một quyết định kiểm soát truy cập.

Đối với các nhà phát triển API, câu hỏi đầu tiên là ai tạo ra giá trị hoặc hành vi. Câu hỏi tiếp theo là ai diễn giải nó. Câu hỏi cuối cùng là kết quả quan sát được nào chứng minh rằng việc diễn giải hoạt động. Ba câu trả lời đó biến một thuật ngữ từ điển thành một hợp đồng giao diện có thể kiểm tra.

Cách mà Tin nhắn JSON-RPC Hình thành Một Cuộc Hội Thoại

Một đối tượng yêu cầu chứa jsonrpc được đặt thành 2.0, một chuỗi phương thức, các tham số tùy chọn, và thường là một id. Các tham số có thể là một mảng cho các đối số vị trí hoặc một đối tượng cho các đối số có tên. Các tham số có tên giảm phụ thuộc ngẫu nhiên vào thứ tự, nhưng tên của chúng phải khớp chính xác với hợp đồng máy chủ.

Một phản hồi thành công lặp lại id của yêu cầu và chứa một thành viên kết quả. Một phản hồi thất bại lặp lại id và chứa một đối tượng lỗi với mã số và tin nhắn, cộng với dữ liệu tùy chọn. Kết quả và lỗi là những thay thế; một phản hồi không nên tuyên bố cả hai kết quả.

Một thông báo bỏ qua thành viên id và yêu cầu máy chủ thực hiện công việc mà không gửi phản hồi. Việc thiếu phản hồi là một phần của giao thức, vì vậy một thông báo không thể xác nhận thành công hoặc phơi bày một lỗi ứng dụng cho người gửi của nó. Chỉ sử dụng nó khi sự không chắc chắn đó là chấp nhận được.

Một lô là một mảng JSON chứa nhiều đối tượng yêu cầu hoặc thông báo. Máy chủ có thể xử lý chúng theo thứ tự riêng của nó, và thứ tự phản hồi không nhất thiết phải khớp với thứ tự yêu cầu. Do đó, khách hàng liên kết các kết quả lô qua id thay vì theo vị trí mảng.

Các thành viên trong một đối tượng JSON-RPC 2.0

Các thuật ngữ sau tách biệt các thành phần thường bị gộp thành một nhãn. Read chúng như các giao diện giữa các bên tham gia thay vì như một trang trí trong một bản theo dõi mạng.

Tại sao JSON-RPC quan trọng trong Thu thập Dữ liệu Web

JSON-RPC có thể thay đổi những gì byte đến, cách những byte đó được diễn giải, hoặc liệu mã trình duyệt có thể quan sát kết quả. Một quy trình thu thập nên xác định tác động đó trước khi thay đổi công cụ. Ghi lại URL đã yêu cầu, URL cuối, trạng thái phản hồi, loại đại diện, các trường giao thức liên quan và một dấu hiệu nội dung kỳ vọng. Hồ sơ gọn gàng đó làm cho một trang chính xác khác với một thông điệp truy cập, màn hình đồng ý, mục tiêu chuyển hướng, khung ứng dụng trống, hoặc mã hóa không tương thích.

HTTP trực tiếp là con đường thu thập đơn giản nhất khi dữ liệu yêu cầu tồn tại trong một phản hồi được máy chủ render mở. Một trình duyệt trở nên liên quan khi nội dung đã được phê duyệt phụ thuộc vào việc thực thi JavaScript, trạng thái do trình duyệt quản lý, điều hướng, hoặc chính sách an ninh của trình duyệt. Hai con đường không nên bị buộc phải trông giống nhau: trình duyệt quản lý cookie, nén, chuyển hướng, CORS và lưu trữ theo quy tắc nền tảng, trong khi một khách hàng trực tiếp tiết lộ một tập hợp mặc định khác.

Tính liên tục phiên quan trọng bất cứ khi nào một phản hồi thiết lập trạng thái cho yêu cầu tiếp theo. Giữ một chuỗi được ủy quyền trong một ngữ cảnh khách hàng giới hạn, bảo tồn ngôn ngữ địa phương và nguồn gốc mạng cần thiết, và tránh trộn lẫn trạng thái từ các công việc không liên quan. Một proxy thay đổi nguồn gốc mạng; nó không tái tạo các tiêu đề, giải mã các đại diện, thực thi kịch bản hoặc cấp quyền truy cập vào nội dung bị hạn chế.

Phân tích chỉ bắt đầu sau khi xác thực đại diện. Xác nhận máy chủ cuối cùng, danh tính chuẩn nơi có sẵn, loại phương tiện, trạng thái giải mã và dấu hiệu kinh doanh cần thiết trước khi trích xuất các trường. Thứ tự này ngăn một trình phân tích biến tài liệu lỗi thành các bản ghi rỗng có vẻ thành công về mặt kỹ thuật.

Các phương tiện trung gian xứng đáng nhận được sự chú ý rõ ràng. Một mạng lưới phân phối nội dung có thể chọn một biến thể được mã hóa, một cổng có thể trả lời OPTIONS, một bộ nhớ đệm có thể tái sử dụng một phản hồi đã thương lượng và một máy chủ ứng dụng có thể thiết lập cookie hoặc các trường ủy quyền. So sánh chỉ mã ứng dụng với đầu ra trang cuối cùng bỏ qua lớp có thể đã đưa ra quyết định.

API Truy xuất Tự động Toàn cầu không có dữ liệu thừa là phù hợp khi một đội cần quản lý việc thu hồi nội dung công khai được phép, bao gồm các trang được trình bày bằng JavaScript. Hợp đồng thu mua vẫn nên xác định mục tiêu, các trường được phép, đại diện mong đợi, dấu hiệu chấp nhận và điều kiện dừng.

Khi nào JSON-RPC là một sự lựa chọn tốt

JSON-RPC có được vị trí trong kiến trúc khi nó thay đổi hành vi sản phẩm cụ thể, yêu cầu tương thích hoặc quyết định chẩn đoán. Những trường hợp sử dụng này mô tả công việc trước và tính năng giao thức sau.

JSON-RPC so với HTTP phong cách REST và gRPC

JSON-RPC tập trung API vào việc gọi phương thức, trong khi HTTP phong cách REST tập trung vào tài nguyên, đại diện và ngữ nghĩa phương thức tiêu chuẩn. gRPC cũng mô hình hóa các phương thức, nhưng thêm một chuỗi công cụ sơ đồ và một ngăn vận chuyển hướng nhị phân. JSON-RPC hấp dẫn khi một bao bì phương thức nhỏ gọn là quan trọng và phương tiện vận chuyển phải vẫn là một lựa chọn riêng biệt.

Một so sánh chỉ hữu ích nếu nó duy trì biên giới lớp. Hai cơ chế có thể đồng tồn tại trong một yêu cầu, và việc thay thế một cái không tự động thay thế cái khác. Tài liệu hóa hành vi đã chọn theo các đầu vào, đầu ra quan sát được, trạng thái thất bại và quyền sở hữu.

Những sai lầm JSON-RPC gây ra kết quả mơ hồ

• Sử dụng thông báo cho các ghi quan trọng. Một thông báo không có phản hồi, vì vậy người gọi không thể biết liệu việc xác thực hoặc thực thi đã thất bại hay chưa.
• Khớp các phản hồi theo vị trí. Thông số kỹ thuật cho phép phản hồi ở bất kỳ thứ tự nào. Khớp mỗi kết quả với id yêu cầu.
• Tái sử dụng id khi các cuộc gọi đang hoạt động. Các id hoạt động trùng lặp làm cho việc tương quan mơ hồ, đặc biệt là qua một kết nối liên tục.
• Xử lý mã trạng thái HTTP như là kết quả phương thức. Khi JSON-RPC hoạt động qua HTTP, trạng thái vận chuyển và kết quả JSON-RPC mô tả các lớp khác nhau. Kiểm tra cả hai.
• Để cho các lược đồ phương thức ngầm định. Bì thư xác định các thành viên giao thức, không phải các loại và quy tắc cho mỗi phương thức ứng dụng. Xuất bản một hợp đồng phương thức riêng biệt.
• Trả lại văn bản ngoại lệ nội bộ. Dữ liệu lỗi có thể tiết lộ chi tiết ngăn xếp hoặc bí mật. Ánh xạ các lỗi thành mã công khai ổn định và các trường chẩn đoán đã được phê duyệt.

Hầu hết các lỗi trở nên dễ chẩn đoán hơn sau khi loại bỏ những giả định về những gì mà một thư viện hoặc trình duyệt đã làm tự động. Ghi lại một dấu vết tối thiểu, xóa đi bí mật, và thay đổi một biến có kiểm soát tại một thời điểm. Mục tiêu là cung cấp một giải thích ổn định cho đại diện đã trả về, không phải là một tập hợp các điều chỉnh tiêu đề không liên quan.

Một Chuỗi Đánh giá JSON-RPC

Chuỗi này hoạt động như một đánh giá thiết kế trước khi ra mắt và như một chẩn đoán sản xuất sau khi có thay đổi hành vi. Nó giữ cho chứng cứ giao thức có liên quan đến kết quả ứng dụng.

1. Kiểm kê mọi phương thức và quyết định xem các tham số của nó là theo vị trí hay theo tên; không trộn lẫn các quy ước một cách tùy tiện bên trong một API.
2. Xác định lược đồ kết quả và mã lỗi công khai cho mỗi phương thức trước khi triển khai các bộ xử lý.
3. Chọn một quy tắc tạo id mà giữ cho nó duy nhất trong các cuộc gọi đang hoạt động và hoạt động trong mọi ngôn ngữ của khách hàng.
4. Tách biệt các lỗi vận chuyển, JSON định dạng sai, đối tượng JSON-RPC không hợp lệ, lỗi phương thức và kết quả thành công trong nhật ký và bài kiểm tra.
5. Kiểm tra thông báo mà không cần mong đợi phản hồi, bao gồm cả thông báo được đặt trong một lô.
6. Xáo trộn thứ tự phản hồi lô trong các bài kiểm tra để chứng minh rằng khách hàng liên quan theo id chứ không phải chỉ số mảng.
7. Tài liệu xác thực, ủy quyền, giới hạn kích thước thông điệp và khung vận chuyển vì JSON-RPC bản thân không định nghĩa chúng.

Kết thúc đánh giá bằng cách lưu một mẫu nhỏ đã chấp nhận và một mẫu bị từ chối với cùng các quy tắc xóa. Các thay đổi trong tương lai có thể được so sánh với danh tính trang đã biết, các trường mong đợi và nội dung đã giải mã thay vì chỉ bộ nhớ hoặc ảnh chụp màn hình.

Ranh giới Bảo mật Bên Ngoài Bì Thư JSON

JSON-RPC không xác thực người gọi, mã hóa lưu lượng, giới hạn kích thước thông điệp hoặc ủy quyền cho một phương thức. Những điều khiển đó thuộc về giao thức và ứng dụng được chọn. Một triển khai WebSocket, một triển khai HTTP và một luồng nội bộ có thể sử dụng cùng các đối tượng JSON-RPC trong khi có những mô hình đe dọa khác nhau.

Tên phương thức và tham số là đầu vào không đáng tin cậy. Xác thực phương thức chống lại danh sách cho phép, xác thực tham số chống lại lược đồ phương thức và áp dụng ủy quyền sau khi danh tính người gọi được thiết lập. Một yêu cầu JSON-RPC cú pháp hợp lệ không phải là sự cho phép để thực hiện một hoạt động.

Phản hồi lỗi nên giúp khách hàng hành động mà không tiết lộ chi tiết triển khai. Mã công khai ổn định, một thông điệp ngắn gọn, và dữ liệu có cấu trúc giới hạn thì dễ theo dõi hơn so với các ngoại lệ thô. Nhật ký có thể giữ một giá trị tương quan nội bộ mà không sao chép đầy đủ các đối tượng tham số nhạy cảm.

Các tiêu chuẩn Định nghĩa JSON-RPC

đặc tả JSON-RPC 2.0 định nghĩa các yêu cầu, phản hồi, thông báo và lô. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong các khách hàng và triển khai được chọn.

tiêu chuẩn trao đổi dữ liệu JSON định nghĩa cú pháp JSON được giao bởi giao thức. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong các khách hàng và triển khai được chọn.

đặc tả OpenRPC cung cấp định dạng mô tả có thể đọc bởi máy cho các API JSON-RPC. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong các khách hàng và triển khai được chọn.

giao thức WebSocket là một phương tiện vận chuyển có thể là liên tục cho các thông điệp JSON-RPC. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong các khách hàng và triển khai được chọn.

Điểm Nhấn của JSON-RPC

JSON-RPC là một giao thức gọi phương thức nhỏ, không phải là một nền tảng API hoàn chỉnh; sự đơn giản của nó hoạt động tốt nhất khi các nhóm rõ ràng xác định các lược đồ phương thức, hành vi vận chuyển, bảo mật và khả năng quan sát xung quanh bì thư.

Đưa quy tắc đó vào một bài kiểm tra chấp nhận. Nêu rõ người tham gia nào gửi tín hiệu, người tham gia nào diễn giải nó, những trung gian nào có thể thay đổi đường đi, và chỉ ra dấu hiệu nội dung nào chứng minh thành công. Điều này làm cho JSON-RPC trở thành một phần của hệ thống có thể quan sát thay vì chỉ là một nhãn đính kèm sau một lỗi.

Tài liệu tham khảo

• Tài liệu API Scraping Universal Không Rác
• Tổng quan sản phẩm API Scraping Universal Không Rác
• Hướng dẫn của Scrapeless về tiêu đề, cookie, phiên làm việc và xác thực đại diện
• Scrapeless trên GitHub