РЕДАКТИРОВАТЬ: Брайан Слесинский только что задокументировал протокол (путем обратного инжиниринга кода): https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
Во-первых, протокол GWT-RPC является асимметричным, поэтому он всегда оптимизирован для клиентской стороны: быстрая десериализация чего-либо, поступающего с сервера, и быстрая сериализация чего-либо для отправки на него.
Очевидно, что это не двоичный файл, как вы подозревали, а текстовый. Протокол клиент-сервер разделяется по конвейеру, а сервер-клиент основан на JSON (с префиксом //OK или //EX для определения успешности или сбоя запроса). Оба используют общие знания сериализуемых классов для сериализации / десериализации; например, обе стороны знают, что у класса X есть два поля, целое число и строка, сериализованные в указанном порядке, поэтому они оба пишут / читают целое число, а затем строку, без необходимости указывать в кодированном формате, какое поле это о.
Протокол GWT-RPC является версионным (он регулярно меняется по мере выпуска новых версий GWT) и использует хэши имен классов и сериализуемых полей, чтобы гарантировать, что клиент и сервер используют одинаковые версии классов (что означает, что вы приходится перекомпилировать и повторно развертывать свой клиентский код каждый раз, когда вы изменяете сериализуемый класс).
Лучшей документацией является код, но вы найдете обзор формата запроса на следующих слайдах: https://www.owasp.org/images/7/77/Attacking_Google_Web_Toolkit.ppt
RequestFactory, в отличие от GWT-RPC, использует симметричный протокол на основе JSON (на основе сериализации JSON в AutoBean), где клиент и сервер могут взаимодействовать, даже если они не скомпилированы из одного и того же кода (ну, в зависимости от изменений, которые вы сделали между версиями конечно), потому что они передают имена классов и свойств.