Thrift 服务与 RESTful 服务哪个更好？
我正处于在 Thrift 和在客户端和服务器之间使用普通 RESTful 服务之间做出决定的关键时刻。此外，考虑到其长期且经过验证的记录，我陷入了是否使用套接字进行通信还是仅使用网络服务的困境。另一方面，Thrift 是未知的，文档较少，而且需要打开端口。我拥有的一种应用程序是一个带有 php（客户端）和 java（服务层）的网站，对于此集成，我正在尝试评估 Thrift/REST。
使用套接字/端口与 8080 相比会面临哪些挑战？
任何方法都会带来性能优势吗？
还有其他选择吗？
谢谢
I am in a juncture to decide between Thrift and using plain RESTful services between client and server. Moreover I am stuck with whether to use socket for communication or just go with webservice as is considering its long and proven track record. Thrift on the other hand is unknown with less documentation and moreover port is needed to be opened. Kind of app I am having is a website wih php(client) and java (service layer) and for this integration I am trying to assess Thrift/REST.
What would be challenge in using socket/ports vs 8080?
Will there be any performance benefit in any of the approaches?
Is there be any other option also?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Web 服务更加健壮，并且随着应用程序的增长可能会更具可扩展性。如果您对处理套接字例程以及与之相关的所有细微差别（套接字连接、断开连接、错误等）没有信心，那么只需使用 php 等方式将服务添加到现有的 Web 服务，或者将 Rails 与 ruby 结合使用，或带有 Java 的 tomcat。
就性能而言，它可能取决于 thrift/restful 接口和底层系统的用例。在很多情况下，您的 api 执行的操作比处理 api 请求更“昂贵”。
至于哪一个，我是 REST 的粉丝，但那是个人喜好。
祝你好运
Web service is a bit more robust and will likely be more extensible as the application grows. If you're not confident in handling the socket routines and all of the nuances associated with that (socket connects, disconnects, errors, etc), then simply adding a service to an existing web service in something like php, or using rails with ruby, or tomcat with Java.
As far as the performance concerns, it can depend on that use case of the thrift/restful interface and the underlying systems.. In a lot of cases, the actions your api perform is more 'expensive' than handling the api request.
And as for which, i'm a fan of REST but thats personal preference.
Good luck