왜 Protobuf 3가 메시지의 모든 필드를 선택 사항으로 만들었습니까?

protobuf의 구문 (3)는 키워드를 삭제 옵션 모든 필드를 만든 required및 optional이전 proto2 구문에서. 개발자의 의견을 읽으면 앞으로 / 뒤로 바이너리 호환성을 향상시키기 위해 수행 된 것으로 보입니다.

그러나 저에게는 패키지 이름의 버전을 지정하고 com.example.messages.v1클라이언트가 이해하는 디시리얼라이저를 구현하도록하면됩니다. 동시에 소프트웨어 엔지니어링 관점에서 유용한 유형으로 언급 된 일부 계약을 제거합니다. 예를 들어

message Location {
   double latitude = 1;
   double longitude = 2;
}

proto3에서는 Location필수 필드 중 하나를 제공하지 않으면 서 반이 지원되지만 완벽하게 유효 합니다.

클라이언트간에 데이터를 교환하기 위해 스키마 기반 직렬화 형식을 만들 때 큰 단점이 아닙니까? 모든 필수 필드에 유효한 값이 있는지 확인하는 추가 검증 코드를 각 클라이언트로 옮기는 것이 나쁘지 않습니까?

proto3는 크로스 플랫폼 시나리오에서 훨씬 더 유용하게 사용할 수 있도록 여러 가지 변경을 수행했습니다. "할당 된"대 "할당되지 않은 기본값을보고하는"의 명시 적 추적은 일부 대상 플랫폼에서 구현하기 가 매우 어려울 수 있으며 사용하기가 혼동 될 수 있습니다. 따라서 proto3는 훨씬 간단한 접근 방식을 채택합니다.

• 암시 기본값은 자연 제로 값 (숫자 / 열거), 거짓 (부울) 또는 빈 문자열 (문자열)
• 내재 된 기본값 만 허용됩니다. 다른 기본값은 허용되지 않습니다
• 필드에 해당 기본값이 있으면 직렬화되지 않습니다. 명시 적으로 0 / false / 빈 문자열에 할당되었는지 여부는 중요하지 않습니다.
• 이로 인해 "명시 적으로 0 값이 할당 됨"과 "값이 할당되지 않음"이 동일하게 보이므로 "필수"개념이 없습니다.

proto3에서는 필수 필드 중 하나를 제공하지 않으면 서 반값이지만 완벽하게 유효한 위치를 만들 수 있습니다.

다른 값은 0입니다. 명시 적 으로 0에 할당 하지 않았다는 사실 은 모순입니다. 이것이 바람직한 지 아닌지는 당신에게 달려 있지만 그것은 나에게 의미가 있으며 다양한 플랫폼에서 많은 "새로운 객체 / 구조체를 초기화"하는 방식입니다.

모든 필수 필드에 유효한 값이 있는지 확인하는 추가 검증 코드를 각 클라이언트로 옮기는 것이 나쁘지 않습니까?

확인할 것이 없습니다! 레이아웃은 값 0이 명시 적으로 할당 된 경우와 정확히 같습니다. 그것이 합법적이라면 합법적입니다. 불법 인 경우 (0은 이해가되지 않기 때문에) 불법입니다. 그러나 명시 적이든 암시 적이든 불법입니다. 관련된 검증 량은 변하지 않습니다.

클라이언트간에 데이터를 교환하기 위해 스키마 기반 직렬화 형식을 만들 때 큰 단점이 아닙니까?

일반적으로 아닙니다. 특히 스키마 버전이 명시 적이므로 특히 그렇습니다. proto2를 사용하려면 : proto2를 사용하십시오. 아무것도 자동으로 변경되지 않습니다.