For the case where you're looking for developers who just want a drop-in way to REST'ify the problem away, while seeing if you can capture the 'backend services' aspect of the problem, I dunno. My feedback is, this is a bit of a short sell. Multiplayer gaming services for developers with a customer-base on the order of 10's or even 100's of k's of users, must be worth the salt, surely, to tackle the backend properly .. i.e. who needs to buy this? Wouldn't developers just make it, easily enough, for themselves?

Second point is, to launch, it would be nice to have big examples for incoming visitors to be attracted to the service.

Apropos the idea of multiplayer gaming, I have found that node.js and a smart bit of client-pool reflection has meant that I don't have to lean heavily on a 3rd-party API framework for the 'backend multiplayer' bit, because after all .. that's the good bit. Today's multiplayer game engine is a few well-spent afternoons with node.js, imho .. it does at least make just-in-time deployment very smooth. Don't forget that this is, also, a place for things like Lua and Rust to excel. I'm not trying to be contrarian, but these are the realms in which you dwell; a multiplayer API+(deployment problem solved with magic), versus having someone built such a thing in a month or 3, themselves, and consequently owning the codebase, because .. after all, the backend is where a lot of the magic happens when you've got 10's of k's of gamers online, and can watch it happen for months on end ..