Is it a good practice in protobuf3 using optional to check nullability?

Question

I noticed that they bring optional back in protobuf 3.15. I'm trying to use optional to check field presence. But I'm still unclear regarding the philosophy behind this.

Here is my usecase:

I'm providing some services that accept protobuf as my input. But the client side is untrusted from my perspective, therefore I have to check the nullability for the input protobuf.

The way I expect is that,

• for a required field, either it's set, or it's null,
• for an optional field, I don't care I can just use a default value and that won't cause any problem from my system

So I end up adding optional to every field that should not be null so that I can use hasXXX to check the presence. This looks weird to me because those fileds are actually required from my perspective, but I have to add optioanl keyword for them all.......I'm not sure whether this is a good practice. Proto experts pls give me some suggestions.

Also the default value doesn't make sense to me at all regarding nullability checking, since zero or empty string usually have their own meaning in many scenarios.

Untenable

Answer 1

The entire point of optional in proto3 is to be able to distinguish between, for example:

1. no value was specified for field Foo
2. the field Foo was explicitly assigned the value that happens to be the proto3 default (zero/empty-string/false/etc)

In proto3 without optional: the above both look identical (which is to say: the field is omitted)

If you don't need to distinguish between those two scenarios: you don't need optional, but using optional also isn't likely to hurt much - worst case, a few extra zero/empty-string/false values get written to the wire, but they're small anyway.

Normalize

Answer 2

Google's API Design guide discourages the usage of the optional keyword. Better practice is to make use of the google.api.field_behavior annotation for describing the field's behaviour.

It is however not recommended to use the optional annotation at all [1]. If one consistently implements the field behaviour annotations then OPTIONAL is redundant and can be omitted.

Check out AIP 203 for an overview of the various behaviour types along with guidelines around the usage of OPTIONAL fields.

In general, Google's API Improvement Proposals are a great reference for good practices in your API design.

Beech

The google.api.field_behaviour=OPTIONAL is different from the protobuf optional keyword, and cannot serve as a replacement. The latter allows you to distinguish default primitive values from unset values, while the former does not. – Overelaborate

Of course this is not a replacement, they are for different purposes. google.api.field_behaviour=OPTIONAL, google.api.field_behaviour=REQUIRED are for documenting APIs. optional is NOT for documenting but for building logic based on field presence information (which is generally considered a bad practice) – Chip