Ask HN: REST architecture: many calls vs. rich responses?

https://news.ycombinator.com/item?id=1666308

by c1sc0 • 16 years ago

1 2 16 years ago

news.ycombinator.com

We're working on a REST API design & are discussing about the trade-offs of doing many calls vs. returning rich responses. Which style do you prefer as an end-developer? Any tips & tricks for API design?

AutomatedTester• 16 years ago

I would do more calls but only where those more calls help with self describing.

REST interfaces should help the caller find what they want to do and how to do it.

kls• 16 years ago

I have to agree with this. I have never seen the Swiss-Army knife servies work well, they lead to confusion and create an extremely complicated API. It is hard to make them comply with a REST architecture and they kill re-usability because different services will most likely require that data + some new data that is not available in the service because it did not exist at the time.

You would be better served to make the services small and specific and then really analyze the data in the services for caching and use the caching mechanism of the browser to limit data request to only those things that change frequently. This will give you the best of both worlds. Specific data points with less frequent requests.

With large aggregated data calls it is hard to cache because of the disparate uses of the data they contain.

As well, If you back end is done correctly and you build your services with no run-time interdependency, it is easy to scale you application for more request. Scaling at the infrastructure level is always easier than custom code written to avoid resource utilization.

Ask HN: REST architecture: many calls vs. rich responses?

Related Stories