In the last 24 hours, data.mtgox.com has served 143513 requests for a total of 25.9 GB bandwidth.
That's just a fraction of what's being served on mtgox.com, but that helps already quite a lot.
There are other reasons for requesting the same API more often than only 5 times per hour, for example when developing client software and testing it. Your API should just be able to take such usage without a problem, after all its mostly only reading and not writing, so it should not put any noticeable stress on your servers.
If that's for uses such as development, then it's fine. Some websites actually hit our ticker backend once for every page load on their side.
And finally: Is there a thread or a section on this forum specifically for mtgox feature requests/problems/questions/etc?
None, but your suggestions are welcome on
info@mtgox.com. I've read what you posted here and will use it. I'm not sure about user-defined order ids, as it's going to be using a lot of storage on our side, and all data is already gzipped if supported by the user agent. We'll be checking your other suggestions.
Requesting the same API more than 5 times per hour can be in production mode too - in case when my engine supports more than 5 currencies orderbooks at the same time - when socket reconnects I will need to synchronize all supported orderbooks in the same moment. Then I request full orderbooks for every currency i support. And first test show the first 5 http requests work and the remaining requests get timout response. Thanks to the quite complext logic of managing timeouts for each currency orderbook my engine did not get blocked yet. But it would be good that you give your understanding of this situation and maybe suggest some possible solution in this case?