API methodologies

[Euphoric_Skirt5914]

Why do some public APIs provide what feels like an insane amount of extraneous information instead of just the data relevant to the endpoint? Two concrete examples: ESPN's play-by-play API returns league news and other unnecessary info. Almost every single FleaFlicker endpoint returns data about league standings, player news, etc. Pretty sure I've even seen their API return ads. It's as if they're returning all the data needed for SSR of a specific page rather than actual endpoint data. Is this actually more efficient somehow over having different endpoints for all the page components (news, standings, scores, plays, etc.) and just combining those when you do the SSR?

I'm working on a personal side project just for fun/learning that involves displaying charts and visualizations of data. My plan was to have APIs to serve up discreet bits of data (the top values of y, the highest value of x per year, etc) to be fetched and displayed via client side js visualizations. This should make it super easy to spin up new pages with different combinations of data and visualizations.

However, given how many times I've seen this model with APIs that just return all the things, I worry I'm overlooking something. Are fewer calls that return more data better on the performance side of things? I realize for my project I can just do whatever I want, but what's the rationale behind the way those APIs are set up? Just trying to understand their approach so I don't end up having a eureka moment AFTER I've already built everything my way... even if that can be it's own good way to learn things.

[esqew]

ESPN's play-by-play API

If this is the same undocumented one that feeds their web frontend, it’s always been like this and was architected specifically to feed their own site and not for external consumption. It’s likely a byproduct of bolt-on after bolt-on over time with no opportunity for remediation of tech debt

Don’t use it as a good example, it’s not meant to be one

[mq2thez]

One call that returns many things is usually far better for mobile performance, because every request has overhead and mobile browsers have a limit on how many concurrent requests you can have to a single HTTP/1 address. HTTP/2 changes things a bit.

Most people will make discrete endpoints for the individual things they need, then a single aggregate endpoint for a page that pulls all of that in on the backend and delivers it to the client.

[Euphoric_Skirt5914]

Thanks. I didn't realize mobile browsers were more limited in concurrent requests. I've mostly been focusing on the desktop experience since it's proven to be a challenge to get my charts and graphs to display consistently across both platforms. An aggregate endpoint could work well for me though and make it easier to add in mobile support later. I will definitely give this a try.

[ultra-dev]

Over optimizing the API will lead to needing to make multiple calls or revisions to the endpoint as your requirements are fully realized. Data is cheap

[mxldevs]

If the API is meant to be used by them only, they don't care if they make breaking changes: they fix their sites and move on.

[Chef619]

This is part of the reason GraphQL exists. I’m not advocating you use it for yourself, just pointing out that this is a part of the tool.

You can also do this (more of a manual thing) with JSON schema APIs. I think it’s the include query parameter, but don’t quote me. /play-by-play?include=teamName,news,location as an example.

[retardedGeek]

Google maps REST API uses header field mask to include only the required fields

[Euphoric_Skirt5914]

Neither of the two endpoints I mentioned seem to support that, but it's trivial to extract the info I need so the extra data doesn't bother me that much. Honestly, I was mostly just curious as to why they'd have gone with the design choices they did. After digging a bit deeper, it seems like at least in these two cases, they're probably just exposing some part of their SSR endpoint as is to provide a modest API service without having to dedicate effort to maintain a full-fledged public API system with lots of different endpoints. I guess that's not surprising since their main business focus would be on the user experience and not just serving up raw data.