Yes, I believe so. Thrift does not support overloaded methods and thus it makes the methods in a service hard to evolve. I prefer to send a a single struct with all/mostly optional arguments. This way if service methods get new parameters the change does not cause a ripple of API breaking changes on the client. Otherwise you end up doing something like:
v1 int method(int x); v2 int method(int x); int method_v2(int x, int y); I think this cleaner in the long run: v1 int method( methodStruct); v2 int method( methodStruct); This is because structs have optional members but functions do no. even though they are marked optional no language supports them even languages that theoretically could support optional arguments like python. On Wed, Feb 11, 2015 at 10:22 PM, Denis Samoilov <[email protected]> wrote: > hello Thrift Community! > > Is there best practice to wrap function params into struct? like: > struct InfoRequest { > 1: required bool getActive > 2: required i32 logLimit > } > ClientsInfoList getExtendedClientsInfo(1: InfoRequest params) > vs > ClientsInfoList getExtendedClientsInfo(1: bool getActive, 2: i32 logLimit) > > > > because this way i can add more optional (with default values) params in > future without breaking backward compatibility, like > struct InfoRequest { > 1: required bool getActive > 2: required i32 logLimit > 3: optional i32 newParam > } > > Thank you! >
