Trước hết có thể tất cả chúng ta đã khá thân thuộc với REST servive. REST service có thể được gọi là một phương pháp để trao đổi tài liệu đơn giản giữu Client và Server. Kỹ thuật giao tiếp dựa trên văn bản đơn giản (JSON, XML), dễ học, dễ gỡ lỗi hơn. Hiện nay nói theo một cách nó khá phổ thông và có không ít phương tiện như Postman, Insomnia … cũng tồn tại để giúp các Developer phát triển các API dễ ràng hơn. Trong nội dung bài viết này tất cả chúng ta sẽ tìm hiểu về một kiểu trao đổi tài liệu k phải là mới nữa nhưng nó có thể hữu ích là Protobuf.

Bạn Đang Xem: Protocol buffers là gì và những điều căn bản cần biết về nó

Protocol buffer còn được biết như protobuf là language-neutral, platform-neutral của google phiên bản nội bộ được công bố vào năm 2001 và phiên bản công khai trước tiên được giới thiệu vào năm 2008 ( Repository ), về cơ bản nó được sủ dụng để Serialized object, có vẻ nó khá giống XML hoặc JSON. Nó lưu trữ tài liệu có cấu trúc có thể được Serialize hoặc De-Serialized tự động hóa bưởi nhiều tiếng nói khác nhau. Nó được thiết kế để trở thành language/platform neutral và có thể mở rộng. Ngày nay, protobuf có tương trợ cho C ++, C, Go, Java và Python.

Protobuf là một open source dùng để làm encode tài liệu có cấu trúc được phát triển tại google. Nó rất hữu ích trong việc phát triển các Khóa học để giao tiếp với nhau qua một wire hoặc để lưu trữ tài liệu. Tất cả những gì bạn phải làm là chỉ định một thông tin cho từng cấu trúc tài liệu mà bạn muốn Serialize (theo định dạng giống như lớp Java) bằng phương pháp sử dụng file đặc tả .proto.

Từ file .proto compiler của protobuf ( protoc ) tạo ra code thực hiện encode tự động hóa và phân tích cú pháp tài liệu protobuf với định dạng Binary hiệu quả, tùy thuộc vào từng tiếng nói nó sẽ tạo ra mã tương ứng .

Tại chỗ này tất cả chúng ta sẽ đề cập đến ưu và nhược điểm của Protocol buffer và một số kiểu khác.

Protobuf

1. Tài liệu rất dày đặc, đầu ra nhỏ.
2. Khó decode mà không biết schema, định dạng tài liệu không rõ ràng và cần schema để biết rõ.
3. Xử lý rất nhanh, nhỏ hơn 3 – 10 lần so với XML hoặc JSON
4. không giành cho con người vì là Binary.
5. Tạo các code truy cập tài liệu dễ sử dụng hơn theo Khóa học.

JSON

1. Con người dân có thể có thể đọc và chỉnh sửa dễ dàng.
2. Có thể phân tích cú pháp mà không cần phải biết schema.
3. Các browser đều tương trợ rất tốt.
4. Ít dông dài hơn XML.

XML

1. Con người dân có thể có thể đọc và chỉnh sửa dễ dàng.
2. Có thể phân tích cú pháp mà không cần phải biết schema.
3. Tiêu đúng cho SOAP…
4. Tương trợ tốt các phương tiện như xsd, xslt, sax, dom …

Xem Thêm : Yamete nghĩa là gì? Sự thật thú vị về nghĩa Yamete bạn biết chưa?

Protobuf rất nhanh nhưng nhưng nhưng có những những tình huống tất cả chúng ta không nên sử dụng nó. Ví dụ như các tình huống ở đây

1. Khi bạn phải hoặc muốn tài liệu con người dân có thể đọc dễ dàng.
2. Tài liệu từ Service được sử dụng trực tiếp bởi Browser.
3. Server của bạn viết bằng ngôn ngư khác ví như Javascript
4. Gánh nặng hoạt động của việc vận hành một loại dịch vụ mạng khác là quá rộng

Cách sử dụng.

Mỗi file .proto khai mạc bằng một khai package , giúp ngăn chặn xung đột đặt tên giữa các Project khác nhau. Về cơ bản, các bạn sẽ xác định cách bạn muốn tài liệu của mình được cấu trúc, sử dụng một mesage format, trong file .proto. File này được sử dụng bởi protoc sẽ tạo ra một file được khái niệm sẵn các phương thức để chúng ta có thể Serialize và Deserialize, theo tiếng nói mà bạn chỉ định (Java, Golang, Python, … ) Bạn cũng có thể xác định một loại message trong .proto như sau. Bạn cũng có thể hiểu xem thêm ví dụ tại developer google.

// Request message for creating a new customer message CustomerRequest { int32 id = 1; // Unique ID number for a Customer. string name = 2; string email = 3; string phone= 4; message Address { string street = 1; string city = 2; string state = 3; string zip = 4; bool isShippingAddress = 5; } repeated Address addresses = 5; } message CustomerResponse { int32 id = 1; bool success = 2; } message CustomerFilter { string keyword = 1; }

Mỗi loại message có một hoặc nhiều field được đánh số duy nhất Các loại message lồng nhau có tập hợp các trường được đánh số duy nhất của riêng chúng. Các loại giá trị có thể là Number, Boolean, String, Byte,cũng luôn tồn tại thể là Collection và Enumeration. Ngoài ra, chúng ta có thể lồng các loại message khác, được cho phép bạn cấu trúc tài liệu theo thứ bậc Theo phong cách tương tự như JSON được cho phép bạn.

Chỉ định Field type

Các Field óc thể được chỉ định là optional, required, hoặc repeated. Không được cho phép các Field type ( enum, int32, float, string … ). Các Field type chỉ là gợi ý để bảo vệ về phong thái Serialize một giá trị Field và tạo định dạng được mã hóa Message của Message của bạn. Định dạng được mã hóa trông giống như một trình diễn phẳng và nén của đối tượng người tiêu dùng của bạn. Các bạn sẽ viết đặc tả này theo cùng một cách chuẩn xác cho dù bạn đang sử dụng protobuf trong Python, Java hay C ++.

Chỉ định Tag

Mỗi Field trong khái niệm Message có một Tag được đánh số duy nhất. Các Tag này được sử dụng để xác định các Field của bạn ở định dạng Message binary và không nên thay đổi khi loại Message của bạn được sử dụng. Lưu ý rằng các Tag có mức giá trị trong phạm vi từ một đến 15 mất một byte để mã hóa, gồm có số nhận dạng và Field type (chúng ta có thể tìm hiểu thêm về điều này trong Mã hóa Protobuf). Các thẻ trong phạm vi 16 đến 2047 mất hai byte. Vì vậy, bạn nên dành các thẻ từ một đến 15 cho những yếu tố thông tin xẩy ra rất thường xuyên.

Xem Thêm : Bột nở Baking powder là gì? cách sử dụng và thay thế baking powder

Số thẻ nhỏ nhất chúng ta có thể chỉ định là một trong những và lớn số 1 là 229 – 1 hoặc 536.870.911. Bạn cũng không thể sử dụng các số 19000 mặc dù 19999 vì chúng được dành riêng cho việc triển khai Protobuf – compiler sẽ khiếu nại nếu như bạn sử dụng một trong những số dành riêng này trong .proto của nó. Tương tự, bạn không thể sử dụng bất kỳ Tag dành riêng trước đó.

Chỉ định quy tắc Field

Bạn xác định các Message field là một trong những điều sau đây

1. required: So với các required field, giá trị ban sơ phải được cung cấp, nếu không field không được khởi tạo.
2. optional: So với các optional field, nếu không khởi tạo, thì giá trị mặc định sẽ tiến hành gán cho field, tất nhiên, chúng ta có thể chỉ định giá trị mặc định.
3. repeated: Field có thể được tái diễn bất kỳ số lần, trong một message được hình thành tốt. Trật tự của rất nhiều giá trị tái diễn sẽ tiến hành bảo tồn.

Lưu ý: các trường tái diễn của rất nhiều kiểu scalar numeric không được mã hóa hiệu quả nhất có thể. Mã mới nên sử dụng tùy chọn đặc biệt quan trọng [pack = true] để đã dành mã hóa hiệu quả hơn. như ở đây

repeated int32 samples = 4 [packed=true];

Enumerations

Khi chúng ta xác định loại message, chúng ta có thể muốn một trong các field của nó chỉ có một trong list giá trị được xác định trước.

enum Foo { FIRST_VALUE = 0; SECOND_VALUE = 1; }

Protocol Buffer cung cấp một số lợi thế quyến rũ so với JSON, XML … để gửi tài liệu qua mạng giữa các internal service. Mặc dù không phải là việc thay thế hoàn toàn cho JSON, XML, nhất là các dịch vụ được sử dụng trực tiếp bởi trình duyệt web, Protocol Buffer cung cấp các lợi thế rất thực tế không chỉ ở những cách được nêu ở trên, mà còn về tốc độ mã hóa và giải thuật, kích thước của tài liệu trên dây, và nhiều hơn nữa.