Apache Thrift 是否验证参数？
我正在考虑使用 Apache Thrift 作为实现 Web 服务的 PHP 服务器。
如果我的 Web 服务被定义为接受两个参数（字符串形式的用户名和整数形式的密码），则会节俭地验证这些类型的参数是否由客户端提供，或者我是否仍然需要执行验证服务器？
我在这里并不是为了清理输入，而是为了向客户端返回有意义的错误响应，以及如果使用不正确的参数调用服务，是否会向服务器发出请求。
I'm considering using Apache Thrift for a PHP server that implements web services.
If my web service were to be defined to accept two parameters - a user name as a string, and a password as an integer - would thrift validate that parameters of those types were supplied by the client, or do I still need to perform validation on the server?
I'm not asking here for the purposes of sanitising input, but rather for returning meaningful error responses to clients, and whether if a service is invoked with incorrect parameters requests will even be made to the server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我了解，检查（如果有的话）是在“库级别”执行的，其中本地类型被转换为 Thrift 类型，代码生成发生在其中。换句话说，如果类型不受尊重，它将取决于您所使用的特定语言（PHP、Erlang 等等）的绑定，以引发有意义的或无意义的错误。但我必须再仔细研究一下。
To my understanding, the check - if any - is performed at "library level", where the local types are translated into Thrift types, where the code generation happens. In other words, it will depend on the bindings for the specific language you are using (PHP, Erlang, whatever), to raise meaningful - or not - errors if types are not respected. But I have to look into it a bit more.
这基本上取决于我们正在谈论哪种验证。
如果需要设置参数，可以将它们设置为“必需”。在这种情况下，在反序列化期间，大多数语言实现（并非全部）都会检查字段，并且每当缺少 reuirwed 参数时就会抛出错误。然而，必需的代价是存在版本控制的潜在问题：一旦 API 发布，您就不能省略必填字段，否则会破坏兼容性。
通常可以通过 _isset 标志来检查正常（“可选”）值的存在，该标志正是为此目的而存在的。这是您自己的代码负责的事情 - Thrift 确实提供了消息传递机制，但当然不提供数据的解释。
如果您的情况下的验证意味着应检查数据格式（字符串和数字）：因为客户端和服务器的代码都是从 Thrift IDL 文件生成的，所以实现将根据以下内容使用正确的字段序列化和反序列化方法： IDL 文件：
如果您出于某种原因需要将密码从 i32 更改为字符串，从技术上讲，这会导致两个更改：
因此它看起来像这样：
由于字段类型和字段用途绑定到数字字段 ID，因此强烈建议在这种情况下使用另一个字段 ID，该字段迄今为止在此范围内未使用。还建议保留 IDL 中的旧字段以指示过时的 ID。
关于“软版本控制”的内容以及“必填”字段的优缺点，可以在 Diwaker Gupta 的“Missing Guide”中找到一个很好的参考。
It basically depends on what kind of validation we are talking.
If the parameters need to be set, you could make them "required". In that case, the fields are checked in most language implementations (not in all) during deserialization and an error is thrown whenever a reuirwed Parameter is missing. However, required comes at the cost of potential problems with versioning: you can't omit a required field once the API has been published, or it will break compatibility otherwise.
The presence of normal ("optional") values can typically be checked by means of the _isset flags, which exist for exactly this purpose. This is something that your own code is responsible for - Thrift does provide the messaging mechanisms, but of course not the interpretation of your data.
If validation in your case means, that the data Format (string and number) should be checked: Because the code for both Client and Server is generated from the Thrift IDL file, the implementation will use the correct field serialization and deserialization method according to the IDL file:
If you Need to Change for whatever reason the Password from i32 into string, technically this results in two changes:
so it looks this way:
As field type and field purpose are bound to the numeric field ID, it is highly recommended to use another field ID in such a case, which is so far unused within this scope. It is also recommended to leabve the old fields in the IDL to indicate outdated IDs.
A good reference about this "soft versioning" stuff and the pros and cons of "required" fields can be found in Diwaker Gupta's "Missing Guide".