Here is the list of all API calls (except nodeInfo and neighbors related calls), with a brief description of what it does. Hope it helps.
(don't hesitate to edit, or leave a comment is something is wrong)
Only for testnet
Run the pow. Safe to run on an non sync node. It make sense to dispatch those calls to the machine with highest computing power.
Broadcast transactions to direct neighbors, can run safely on a desynchronised node
Search for transactions. Results will be more accurate on synced node
Get balances on adresses. Results will be more accurate on sync node (this call is probably used by some wallet implementation as pre-check of the validity of the transaction)
Check if transactions are referenced by another set of transactions. (typical use case is to check if a particular transaction is validated by a milestone)
It make more sense on a fully sync node.
Return the tips in a specific IRI instance
Make sense on any node, mainly for monitoring IMO
An IRI instance keep an in memory cache of transactions that don't have any approvers yet (i.e. tips). This call returns the content of this cache. In other words, this call is just a way to be informed of the internal state of the IRI and I don't think it can be useful from a purely functional perspective. (i.e. picking tips from here to attach a transaction don't make sense because the consistency check is not done)
This trigger the random walk, therefore it's very important to execute this on a fully-sync node.
Return transactions trytes. Results will be more accurate on sync node.
Shouldn't be remotely accessible (see Why is anyone with API access allowed to cancel the 'attachToTangle' operation of another user?)
It simply store a batch of transactions in the local tangle (don't broadcast).
I don't see a use case for this one. Can be useful for maintenance maybe ? IMO, this shouldn't be remotely accessible. This call is used by spammers. Don't requires a fully sync node.
It appears that spammers use it generaly in conjuction with broadcast transactions. In this case if you "storeTransactions" on node A, and just after that "broadcastTransaction" on node B : this won't broadcast anything.
It don't change the fact that those calls are stateless, it's just that the current usage by spammers make the fair assumption that 2 successive calls to store, then broadcast will be executed on the same instance (but nothing in the protocol offer that guarantee).
Return the transactions known only by their hash. (details of the transaction aren't yet in the local tangle)
Make sense on any node, mainly for monitoring.
When a node receive a transaction, this transaction contains the hash of the branch and trunk transactions. If one of them(or both) is(are) not in the local tangle, then the hash(es) is(are) added to a queue of "missing transactions".
This call return that queue. The size of the queue is an interesting indicator to evaluate the "sync state" of the node.
Check consistency of a set of transactions. It make more sense to run it on fully sync node.
This call is use to prevent address re-use. Results will be more accurate on sync node (this call is used by some wallet implementations)
Invocation of IXI module (probably better to run of fully sync node)