I've been working on implementing a customer-facing REST API at work the last few weeks. Although there's not yet a requirement for it, I think it'd be really nice to have analytics for this.
For example, to track how many requests are being made by which client, etc.
I'm planning on creating an analytics app over the weekends that will have to receive data from our API server. I haven't done anything like this before so I have a few design questions:
What method/protocol would work best for this?
I've been thinking of going with a push model, where the API server would push logs/data to my analytics app such that it could persist it and I can create a nice UI with charts, graphs, etc. I was originally going to just use REST with HTTP since that's what I'm most familiar with. But I was also considering using web sockets. I've done some research and I think I understand the differences, but it's still not very clear to me which the better choice would be.
A design decision that may affect the choice is this: Should the API server be pushing these logs/data every time a request is made? If so, I'm guessing websockets may be better since it's better suited to handle numerous smaller requests.
On the other hand, this API server may be receiving tons of requests. I was also thinking of maybe collecting a bunch of request log/data first, then sending it over as a batch to the analytics app (maybe based on a time interval, or even based on a count). If this is the better approach (bulk vs individual pushes), would REST make more sense here?
I'd love to hear any thoughts and comments on this. I'm here to learn from everyone, thanks so much for your time!