Một bài viết chi tiết theo dõi sự phát triển từ XML đến JSON rồi đến CBOR đã gây ra cuộc thảo luận sôi nổi trong cộng đồng lập trình viên, với nhiều người đặt câu hỏi liệu CBOR có xứng đáng được chú ý và chỉ trích việc bỏ qua mối quan hệ của nó với MessagePack. Bài viết này, định vị CBOR như một định dạng dữ liệu then chốt, đã thu hút sự hoài nghi từ cộng đồng kỹ thuật.
Những Tuyên Bố Quảng Bá CBOR Khiến Nhiều Người Nghi Ngờ
Một số lập trình viên đã bày tỏ lo ngại rằng bài viết này giống như tài liệu marketing hơn là phân tích kỹ thuật khách quan. Những người chỉ trích chỉ ra rằng trong khi XML và JSON là những định dạng được công nhận rộng rãi, việc gọi CBOR là then chốt có vẻ quá sớm khi so sánh với các định dạng nhị phân đã được thiết lập hơn như Protocol Buffers, Apache Avro, và Cap'n Proto. Nhiều lập trình viên thừa nhận họ chưa bao giờ gặp CBOR trong thực tế, với một người lưu ý rằng lần tiếp xúc duy nhất của họ là trong quá trình phát triển mã QR hộ chiếu thời COVID.
Thời điểm và giọng điệu của bài viết đã khiến một số người đặt câu hỏi về động cơ đằng sau việc quảng bá một định dạng vẫn còn tương đối nhỏ. Tuy nhiên, những người ủng hộ lập luận rằng vai trò của CBOR trong các tiêu chuẩn mới nổi như xác thực WebAuthn và FIDO2, nơi nó xử lý trao đổi passkey, chứng minh tầm quan trọng ngày càng tăng của nó trong các giao thức bảo mật.
Các trường hợp sử dụng và việc áp dụng CBOR
- WebAuthn/FIDO2: Được sử dụng cho việc trao đổi xác thực passkey
- Giao thức CoAP: Giải pháp thay thế HTTP nhẹ cho các thiết bị IoT
- COSE: CBOR Object Signing and Encryption dành cho bảo mật
- Quản lý thiết bị IoT: Các giao thức OMA-DM/LWM2M
- Biểu diễn chứng chỉ: Chứng chỉ X.509 nhỏ gọn C509
- Dịch vụ AWS: Bắt đầu hỗ trợ trong các API xử lý dữ liệu lớn (2025)
Những ưu điểm chính:
- Kích thước thông điệp nhỏ hơn JSON mà không cần nén
- Định dạng tự mô tả (không cần schema)
- Có thể mở rộng thông qua các thẻ ngữ nghĩa đã đăng ký IANA
- Được tối ưu hóa cho môi trường hạn chế/IoT
Thiếu Kết Nối MessagePack Báo Hiệu Cờ Đỏ
Một chỉ trích đáng kể tập trung vào việc bài viết không thừa nhận mối quan hệ của CBOR với MessagePack, một định dạng nhị phân trước đó có chung mục tiêu và nguyên tắc thiết kế tương tự. Sự thiếu sót này đã được gắn nhãn là cờ đỏ bởi các lập trình viên có kinh nghiệm hiểu bối cảnh lịch sử. Mối quan hệ giữa các định dạng này rất quan trọng để hiểu vị trí của CBOR trong hệ sinh thái, vì chúng giải quyết các vấn đề tương tự với các cách tiếp cận có thể so sánh được.
Chà, CBOR chính là MessagePack. Carsten Bormann đã fork MessagePack, thay đổi một số giá trị tag, viết một tiêu chuẩn xung quanh nó, và gửi nó đến IETF trái với mong muốn của những người tạo ra MessagePack.
Bối cảnh lịch sử này tiết lộ rằng CBOR không hoàn toàn mới mà thay vào đó xây dựng dựa trên công việc hiện có, khiến việc trình bày của bài viết có thể gây hiểu lầm cho những độc giả không quen thuộc với lịch sử định dạng nhị phân.
So Sánh Nén Đáng Chú Ý Bị Thiếu
Một điểm tranh cãi khác liên quan đến việc thiếu so sánh giữa CBOR và JSON được nén. Trong khi bài viết quảng bá lợi thế về kích thước của CBOR so với JSON thuần túy, nó không đề cập đến hiệu suất của CBOR so với JSON với các kỹ thuật nén tiêu chuẩn như gzip hoặc zstd, được triển khai rộng rãi và trong suốt với người dùng. Sự thiếu sót này có vẻ đặc biệt đáng kể vì nén thường được sử dụng trong các ứng dụng web và có thể thu hẹp đáng kể khoảng cách về kích thước mà CBOR tuyên bố là lợi thế.
Việc thiếu so sánh này đã khiến một số người gợi ý rằng nó đã được cố tình loại trừ để duy trì một câu chuyện có lợi cho CBOR, tương tự như cách các sản phẩm cạnh tranh tránh làm nổi bật điểm mạnh của đối thủ trong tài liệu marketing của họ.
So sánh CBOR vs JSON vs XML
| Tính năng | XML | JSON | CBOR |
|---|---|---|---|
| Loại định dạng | Ngôn ngữ đánh dấu cho tài liệu | Định dạng trao đổi dữ liệu | Định dạng dữ liệu nhị phân |
| Có thể đọc được | Có | Có | Không |
| Kích thước thông điệp | Lớn nhất (thẻ dài dòng) | Trung bình | Nhỏ nhất (mã hóa nhị phân) |
| Tốc độ phân tích | Chậm nhất (phân tích phức tạp) | Nhanh | Nhanh nhất (giải mã nhị phân) |
| Hỗ trợ trình duyệt gốc | Có | Có | Không |
| Hỗ trợ lược đồ | DTD, XSD | JSON Schema | Thẻ ngữ nghĩa |
| Bình luận | Có | Không | Không |
| Dữ liệu nhị phân | Yêu cầu mã hóa Base64 | Yêu cầu mã hóa Base64 | Hỗ trợ gốc |
Kiểm Tra Thực Tế Việc Áp Dụng Định Dạng Nhị Phân
Bất chấp những ưu điểm kỹ thuật của CBOR, cuộc thảo luận tiết lộ một thực tế rộng hơn về việc áp dụng định dạng nhị phân. Nhiều lập trình viên vẫn cảm thấy thoải mái với khả năng đọc được của con người và khả năng debug của JSON, đặc biệt khi kết hợp với cơ sở hạ tầng nén hiện có. Bản chất nhị phân của CBOR, mặc dù hiệu quả, nhưng hy sinh khả năng dễ dàng kiểm tra và debug trao đổi dữ liệu, điều này vẫn có giá trị trong nhiều kịch bản phát triển.
Một số lập trình viên ủng hộ việc tạo ra các định dạng nhị phân tùy chỉnh khi hiệu suất là quan trọng, lập luận rằng lợi ích về tốc độ của mã hóa nhị phân đủ lớn để biện minh cho nỗ lực phát triển bổ sung. Tuy nhiên, những người khác thích các giải pháp được tiêu chuẩn hóa như CBOR vì khả năng tương tác và giảm gánh nặng triển khai của chúng.
Kết Luận
Cuộc tranh cãi xung quanh bài viết tập trung vào CBOR này làm nổi bật những thách thức trong việc quảng bá các định dạng dữ liệu mới hơn trong một hệ sinh thái mà JSON đã đạt được sự áp dụng gần như phổ quát. Trong khi CBOR phục vụ các vai trò quan trọng trong môi trường hạn chế và các giao thức bảo mật, việc định vị nó như một người kế nhiệm chung cho JSON có vẻ quá sớm. Phản ứng của cộng đồng nhấn mạnh tầm quan trọng của bối cảnh lịch sử trung thực và so sánh toàn diện khi đánh giá các định dạng trao đổi dữ liệu. Khi Internet of Things tiếp tục mở rộng, CBOR có thể tìm thấy vị trí thích hợp của mình, nhưng việc thay thế JSON trong phát triển web chính thống vẫn khó xảy ra do tính đơn giản và hỗ trợ hệ sinh thái của JSON.
Tham khảo: From XML to JSON to CBOR