I'm designing a distributed game server which will support both browser and UE4 clients (hopefully both over HTTP for simplicity) and I keep butting my head against REST and doing semantic backflips to get the logic I want put in place.For some things, REST makes perfect sense - get a list of games, create a new game, get metadata about a specific game, etc.But for other things, the client really only wants to generate an event - I joined game X, I performed action B in game X, or receive notification that an event occurred - player A joined the game you are in, player A performed action X in the game you are in, etc.  Inside the REST world, you can make this work (believe me, I've tried) but it always involves some peculiarity that either distorts the domain model to make it fit the semantics of REST or distorting REST to make it fit the semantics of the domain model.Is there any framework or paradigm for creating such a pub/sub model that supports interaction from the browser?  My current idea is to hook up a websocket -> MQ proxy and use an MQ server as an event bus, but the problem is I'm finding it hard to find any such proxies and I'm not sure what the security implications of this architecture actually are (in particular I'm worried about protection against DDoS attacks, where multiple distributed users could spam the MQ and saturate it, causing the whole system to fail).Websockets are also not preferable as, while UE4 supports HTTP out of the box, I'm not aware of it having any websocket support so I would need to find and link a C++ websocket library to the game client and that already sounds painful.
Event-based over-HTTP framework
java;rest;web services
If you are looking for simplicity, you'll probably end up using WebSockets. In terms of simplicity, it has two major benefits:Lots of libraries for many programming languages make it easy to set up.Since it uses port 443 (or 80) and is mature enough to be supported by a broad range of software products, you'll have less problems with firewalls, proxies, reverse proxies, etc.With a help of a message queue service, you can achieve a highly scalable platform where, in order to support a growing number of requests and users, you'll simply add nodes to MQS, or servers which will upstream MQS events up to the client through WebSockets. Popular MQS systems include a support for WebSockets, but scalability concerns may require a hand-made solution.DDoS attacks can be avoided in a similar way you would do it for a simple REST service. WebSockets being a bidirectional communication protocol, it's technically possible to use it to send messages from client to server, not barely receiving messages from the server. However, you may also want to use WebSockets exclusively to push events from the server to the client, and keep REST requests for anything else. In both cases, your application should position itself as an intermediary between the client and the MQS, not only to protect you against DDoS, but simply to sanitize the inputs and provide an abstraction level. By comparison, the fact that a website uses an SQL database doesn't mean that the clients are able to run SQL queries directly; with MQS, it's exactly the same thing.If you're at a level where WebSockets becomes a bottleneck (although I never developed any game, I could imagine that some games can hit the bottleneck), then and only then do you need to search for an UDP-based replacement.