REST efficiency on count and sum methods

Question

For example, if I have a Customer Transactions Table and I create a REST for it. The fields are: date, description, and total_amount.

I am trying to figure out which one is much more efficient when you get the sum and the count of the transactions:

1. You create a REST for /transactons URI and it lists down all the transactions. Then, you sum all transactions using javascript and you count all transactions using javascript.

2. You create a REST for /transactions/count and /transactions/sum URI and lists down count and sum for all transactions. Then, get the count and sum using javascript.

I'm wondering which one is a better way.

• Jacek Cz: Seems many better was are present. Your problem is strictly serveside (I understand many modern webmasters compute everything on client side, i dont accept this). You can do /transaction/sumation and return all possible sums, average, count in one packet. BTW Im after discussion about REST (position: REST is overused when should be used business methods and stronger webservices). This problem seem in this class (IMHO)

Answer 1

It depends on how many transactions you expect. In general, it seems that if you only want the sum and count then transferring all the details is inefficient.

However, if the number of transactions is very small then the overhead of multiple requests might be more inefficient.

Personally, I like the second option, but I would add a third REST endpoint /transactions/aggregate that returns some or all of the aggregate data.

• Jimmy Hoffa: +1 for the general statistics endpoint of "aggregate" or sometimes a "stats" etc. There are always some small set of commonly relevant aggregates which can be put together for ease of reporting, like average transaction amount, average transaction time, largest transaction, smallest transaction etc etc