Those APIs where replay attack is potentially dangerous should add timestamp as the part of the request (signature is created from both request and response).
PS to the earlier said: Make sure you always include a signature generation or date into the signed portion, even when the API doesnt immediately require it. In the firstbits example, imagine you would find a bug in the code someday and a few of the addresses were matched in a wrong way. With date or generation information you could then "revoke" the old body of signed snippets by requiring date/generation > X both on the server (to trigger recreation of data+sig) as well as on the updated clients (as security measure).
As for market stats and other things you mentioned, of course you could also cache those pieces of information. Just make up a time grid, in accordance to how often you poll the information yourself. It doesnt make sense to sign it at a higher rate than they can change (which is almost entirely dependant on your pollrate).
You can then hand out the same signed piece(s) many times to many clients.
You can also hand out old (cached) pieces, to give historical information to the clients. However, it makes sense to "compress" the many pieces of information within one timeperiod into a single (newly signed) packet once the timeperiod is over. This reduces the amount of signature verifications on the client side, yet doesnt greatly increase the signature load on the server.
For example, after 15 minutes, you combine the 15 1-minute pieces into one 15-minute piece. Every 4 hours you do the same. Every day you combine the whole day, every week, every month and every year. With every higher timeperiod you can also reduce the "resolution" to avoid excessively growing the size of the datasets. The client can then easily assemble price information for practically every imaginable time ranges, with only few signature verifications. All just from cached information and
nothing individually signed ("just for them").
For moments where you cant query prices yourself (e.g. network problems), you could insert a packet saying so, and sign that. The client can then check its local time and know that it has complete information from your server, despite the lack of data.
But make sure that you dont put too much effort on features that maybe arent useful later on. If you poll prices from doubtful sources using insecure protocols and then sign it, the high quality signature from your server wont serve much purpose. It may even be misleading then..
Always follow the KISS principle (Keep It Simple, Stupid). In electronics we say that the best component is one that you can eliminate. Once eliminated, the component will not have solder problems, it will not fail throughout the whole lifetime of the product, and it adds 0.00 to the BOM. The same goes for software. If you create an elegant design on the API level, your backend can be beautifully simple, and your clients can be too. But its all up to knowing (in advance) where you want to go and what you want your software to do.
This is the hard part of it, and choosing pieces like signature algorithms just for "familiarity" can be a lottery in this respect. Maybe such a tiny decision can bring your network down when it is supposed to just scale up nicely. I dont know the details of what you want to do (and maybe you dont fully know either). So I am sorry I cant give detailed advice.
Good luck with the project.