将 HTTP RESTfull API 请求从 http 服务器转发到我的应用程序
我对我正在开发的应用程序的设计有疑问。
我制作了一个 24/7 开放套接字的整体 Java 应用程序，类似于游戏服务器。我只是想说它是一个单一的 jar 应用程序，而不是基于模块化 servlet/页面的 Web 应用程序。
我现在想向此应用程序添加 RESTful API。因此人们/客户端可以向我的应用程序发出 HTTP 请求以获取某些信息。由于我的 java 应用程序的整体性，我不确定如何实现它。另一件重要的事情：我期望每秒有多个请求，所以如果我可以让现有的 http 服务器处理这些请求，并以某种方式将它们转发到我的应用程序以设置回复，并让 http 服务器发送，那就太好了再来一次。
我想到的一些事情：
将我的应用程序包装在 tomcat 应用程序中，尽管我不确定 tomcat 是否可以连续运行应用程序，而不是根据请求映射到 servlet。
打开一个套接字并自己解析传入的http请求（或者可能有一个库？）。我担心这会对性能产生影响，并且宁愿使用现有的 http 服务器，因为它们针对高流量进行了优化。
使用现有的http服务器来处理请求（apache、lighttp等）并让它通过scgi之类的东西将请求转发到我的应用程序，或者使用可以通过XMLRPC转发的服务器。是否有其他技术/协议可以做到这一点？
关于如何处理这个问题有什么建议吗？ 谢谢！
I have a question about the design of an application I'm working on.
I made a monolithic java application with sockets open 24/7, something like a game server. I'm just trying to say it's a single jar application instead of a modular servlet/page based web application.
I would now like to add a RESTful API to this application. So people/clients can make HTTP requests to my application to obtain certain info. Because of the monolithic nature of my java application I'm unsure of how to implement this. One other important thing: I'm expecting multiple requests per second, so it would be nice if I could have an existing http server handle the requests, and somehow forward them to my app to set up a reply, and have the http server send it again.
Some things I have thought of:
wrap my application in a tomcat application, although I'm not sure if tomcat can run an application continuously instead of mapping to servlets on request.
open a socket and parse incoming http requests myself (or there is propably a lib for that?). I fear this will have an impact on performance, and would rather use existing http servers because they are optimized for high traffic.
use an excisting http server to handle the requests (apache, lighttp, ...) and have it forward requests to my app via things like scgi, or use a server that can forward via XMLRPC. Are there any other technologies/protocols to do this?
Any advice on how to handle this?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会尽可能地将 RESTful 服务端点与原始应用程序解耦。这允许您扩展（为 REST 端点添加多个服务器），而且还可以更改原始应用程序，而无需直接更改 REST API。
客户端 <== REST (HTTP) ==> RESTful 端点 <== 传统（套接字）==>遗留后端因此，您的 REST 服务器一方面是您客户端的服务提供者，但同时也代表您原始后端的客户端。
我会设计 RESTful API，然后选择现有的 Java REST 框架之一（例如 Restlet），并实现 REST 服务本身。同时，您可以开始使用套接字在 REST 服务器和原始后端之间实现网关。
注意可扩展性和性能（即，您可能希望使用连接池作为
rest <=>后端桥，而不是为每个传入的 API 请求生成一个套接字），并考虑 HTTP 的可能优势。只要后端应用程序逻辑允许，当您能够使用缓存等时，您可能会受益。I'd decouple your RESTful service endpoint as much as possible from your original application. This allows you to scale (add multiple servers for your REST endpoint), but also to change your original application without having to change your REST API directly.
Clients <== REST (HTTP) ==> RESTful endpoint <== legacy (sockets) ==> Legacy backendSo your REST server is one the hand a service provider for your clients, but represents at the same time also a client for your original backend.
I would design the RESTful API and then pick one of the existing REST frameworks for Java, like Restlet, and implement the REST service itself. At the same time you can start implementing a gateway between the REST server and your original backend, by using sockets.
Pay attention to scalability and performance (i.e. you may want to use connection pools for the
rest <=> backendbridge and not spawn a socket per incoming API request) and also think of possible advantages of HTTP. You might benefit when you're able to use caching, etc. as far as your backend application logic allows so.