Why do some public APIs seem to provide an overwhelming amount of extra information rather than just the relevant data for the endpoint? For example, ESPN's play-by-play API includes league news and other seemingly unnecessary details, and many FleaFlicker API endpoints return data about league standings, player news, and even ads. It feels like they're returning the data needed for server-side rendering (SSR) of a complete page instead of just the specific endpoint data. Is this approach actually more efficient than creating separate endpoints for different components (like news, standings, scores, etc.) and then combining that data for SSR?
I'm currently working on a personal side project for fun and learning, where I plan to display charts and visualizations of data. My initial idea was to use APIs that serve specific data points, enabling easy display of various combinations of visualizations. However, seeing so many APIs that provide all kinds of data makes me wonder if I'm missing something. Are fewer calls returning more data better performance-wise? I'd like to understand the rationale behind these API designs so that I don't retrospectively realize I've approached my project the wrong way once it's done, even if learning from mistakes is part of the process.
4 Answers
Having a single API call that returns multiple pieces of data is generally beneficial for mobile performance because mobile browsers are limited in how many concurrent requests they can handle. Each request has some overhead, and consolidating these into fewer calls can enhance performance. Typically, developers create individual endpoints for specific needs but also have an aggregate endpoint to gather everything on the backend and send it all to the client.
If the ESPN API is the same one that supports their web frontend, it really isn't designed for external usage. It's likely just a result of various modifications over time without addressing the underlying technical debt. So, I wouldn't consider it a good model for setting up your own API.
This issue is actually part of the reason why GraphQL was created—to allow developers to request just the data they need. While that might not fit all projects, it's important to know there are methods like using specific query parameters in standard APIs to include only necessary data. For example, an endpoint request might look like "/play-by-play?include=teamName,news,location" to tailor the response.
The Google Maps REST API has a similar feature where you can use header field masks to specify only the needed fields.
Be careful not to over-optimize your API during the early stages. Doing so might require you to make multiple calls or change the endpoint as your project evolves. In many cases, data is fairly inexpensive and you can retrieve more without heavy performance hits.
That makes sense! I hadn’t realized that mobile browsers had limits like that. I’ve been more focused on desktop compatibility. Using an aggregate endpoint could really simplify things for later mobile support.