CertPal

Developers on the web increasingly deal with remote APIs. SOAP Web services / REST rest services are consumed by a myriad of consumers. What format this communication should be carried on is a matter of debate. Each format has its own pros and cons. Inevitably any format that is sent / received from the service needs to be serialized and deserialized. There is a cost associated with this process and the bulky nature of payloads (XML is pretty verbose for example) becomes a factor too. To address these problems you can switch to alternate formats such as google protobufs and message pack.

• A lighter payload
• Better serialization / deserialization performance
• Payload is not verbose

• Lack of tooling / plugins can be a cause for concern
• Debugging the format over the wire can prove troublesome
• Documentation and support are as vibrant as the community behind the format

Google enables protocol buffers by defining structures with .proto files like so. The .proto files are compiled using protoC to produce java , C++ , python related artifacts which are used in the serialization / deserialization process.

message Person {
required int32 id = 1;
required string name = 2;
optional string email = 3;
}

Message pack achieves the same with annotations (in Java. There is also support for dynamic typing)

@MessagePackMessage
public static class MyClass {
public String str;
public double num;
// new field
@Optional
public int flag = 0;
}

Custom formats are advisable for any service that is consumed internally within your network (Google actually mentions this in the protocol-buffers landing page). The cons mentioned above can make it difficult to expose such formats to the outside world in general. Formats like XML and JSON have better tooling and support than propritary formats. Should you chance upon the need to provide an alternate format to consume your services internally, take a look at the protobufs message pack, thrift etc.