Это в основном зависит от того, о каком подтверждении мы говорим.
Если параметры необходимо установить, вы можете сделать их «обязательными». В этом случае поля проверяются в большинстве языковых реализаций (не во всех) во время десериализации, и возникает ошибка всякий раз, когда отсутствует повторный параметр. Тем не менее, обязательное значение возникает за счет потенциальных проблем с управлением версиями: вы не можете опустить обязательное поле после публикации API, иначе это нарушит совместимость.
Наличие нормальных («необязательных») значений обычно можно проверить с помощью флагов _isset, которые существуют именно для этой цели. Это то, за что отвечает ваш собственный код - Thrift обеспечивает механизмы обмена сообщениями, но, конечно, не интерпретацию ваших данных.
Если проверка в вашем случае означает, что формат данных (строка и число) должен быть проверен: поскольку код для клиента и сервера генерируется из файла Thrift IDL, реализация будет использовать правильный метод сериализации и десериализации поля согласно файлу IDL:
Service sample
{
bool Login( 1: string Name, 2: i32 pwd)
}
Если вам необходимо по какой-либо причине изменить пароль из i32 в строку, технически это приводит к двум изменениям:
- удалить поле пароля с идентификатором 2, за исключением , если поле "обязательное"
- добавить новое поле с новым ID 3
так это выглядит так:
Service sample
{
bool Login( 1: string Name, /*2: i32 _deprecated_pwd*/, 3: string pwd)
}
Поскольку тип поля и назначение поля связаны с числовым идентификатором поля, настоятельно рекомендуется использовать другой идентификатор поля в таком случае, который до сих пор не используется в этой области. Также рекомендуется оставить старые поля в IDL для указания устаревших идентификаторов.
Хорошую справку об этих «мягких версиях», а также о плюсах и минусах «обязательных» полей можно найти в «Руководстве по отсутствию» Дивакера Гупты.