反正目前我们都是返回字符串的,没错就是为了可读性。
至于什么字符串不标准,大小写神马的,这些完全是技术和管理的问题。如果管理混乱,用int更乱,因为字符串你还可以看出来错了,而int你根本不知道啥意思。
说白了,任何一个字符串字面量如果要在两个地方出现,就必须写成一个const(或static readonly)的字段,何况是用作协议的规范。
既然都是用的同一个字符串,那什么大小写空白等问题怎么可能会存在?
既然服务器端有一个固定的枚举,那么到底是1,2,3还是owner,member,none,本质上都是常量,常量和常量之间本来就没区别,如果字符串会出问题,那么换个格式照样会出问题。所以,在没有极端性能要求的情况下,我选择可读性更好的字符串。
关键在于,你要把这个字符串当成一个token而不是一个message,一个具备更好可读性的token。
再补充一些好了。
即使是为了减轻传输性能负担,我们也会倾向于采用代码(缩减的字符串),而非毫无意义的数字序号,因为人对于代码的记忆要比序号好得多。
但是有一个地方我是建议使用纯数字编码,那就是显示给用户看的错误编号。
有两个原因:
其一是有些信息我们不想让用户知道的太具体。
其二是出现这种情况的时候,我们是需要用户反馈这个错误给我们的,而用户都是非专业人士,对于他们来说1012这样的错误代码,比invalid username这样的信息更容易反馈给我们。后者会导致用户在反馈问题的时候加入自己的一些看法,最终通过客服再转回到技术部的时候,可能得到完全不同的反馈。例如用户完全可能分不清invalid username和invalid user的区别,但是如果提供一个完全不知道是什么意思的编码,如1012,1053这样的东西,那么在用户->客服->技术部门这个信息传递过程中,失真的可能性就降低很多了。