JSON에서 Protobuf로 이동하십시오. 그만한 가치가 있습니까?

XML 또는 JSON (WCF)을 제공 할 수있는 REST 웹 서비스가 있습니다. Protobufs를 구현한다는 아이디어를 가지고 놀았습니다. 왜?

찬성

1. 서버의 부하가 적습니다.
2. 메시지 크기가 작을수록 트래픽이 줄어 듭니다.
3. 지금보다 나중에 전환하는 것이 더 쉽습니다.

단점

1. 구현해야 함
2. 디버깅을위한 메시지 문제 해결 / 스니핑이 더 어려워집니다.
3. 서버에서 GZip을 사용할 수 있으며 JSON은 많은 트래픽을 소비합니다.

이것에 대한 당신의 제안이나 경험은 무엇입니까?

구현의 비즈니스 가치가 비용을 초과합니까?

구현하는 경우 서버뿐만 아니라 모든 클라이언트를 변경해야합니다 (두 형식을 모두 지원하고 필요에 따라 클라이언트 만 변경할 수 있음). 시간과 테스트가 필요하며 이는 직접 비용입니다. 프로토콜 버퍼를 이해하는 데 걸리는 시간 (특히 필드를 필수 또는 선택해야하는 이유)과 프로토 타입 컴파일러를 빌드 프로세스에 통합하는 데 걸린 시간을 과소 평가하지 마십시오.

값이 그것을 초과합니까? "우리의 대역폭 비용은 매출의 X %이며이를 지원할 수 없습니다"라는 선택에 직면하고 있습니까? 또는 "JSON을 지원하기 위해 서버를 추가하기 위해 $ 20,000를 소비해야합니까?"

긴급한 비즈니스 요구가없는 한 "프로"는 실제로 전문가가 아니라 조기 최적화입니다.

나는 protobuf를 추가하기 전에 api와 누군가를 유지한다 ( "더 빠르기 때문에"). 페이로드가 작기 때문에 RTT가 더 빠른 유일한 방법이며 JSON 압축으로 해결할 수 있습니다.

나에게 불쾌한 부분은 프로토 타입을 유지하기위한 상대적인 작업입니다 (JSON과 비교). Java를 사용하므로 JSON에 Jackson 객체 매핑을 사용합니다. 응답에 추가한다는 것은 POJO에 필드를 추가하는 것을 의미합니다. 그러나 protobuf의 경우 .proto 파일을 수정 한 다음 직렬화 및 역 직렬화 논리를 업데이트하여 데이터를 프로토콜 버퍼 안팎으로 POJO로 이동시킵니다. 누군가가 필드를 추가하고 프로토콜 버퍼의 직렬화 또는 역 직렬화 코드를 입력하는 것을 잊어 버린 릴리스가 두 번 이상 발생했습니다.

클라이언트가 프로토콜 버퍼에 대해 구현 했으므로 거의 벗어날 수 없습니다.

당신은 아마 이것으로부터 추측 할 수 있습니다, 내 조언은하지 않습니다.