I can't see the need for an API to star repos at all. There shoulnt even BE a permission, let alone one that is opaquely labeled.
For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.
I'd be careful to not make it recursive, at least - only look at direct dependencies.
This is a very common opinion of people who consume APIs, but people maintaining the APIs often feel differently. Every API endpoint is a promise, and it's also a constraint on future innovation. Firefox is a good example, in that their old API allowed extensions to "intimately intertwine" [1] themselves, which proved a huge barrier to improving the Firefox core.
[1] https://arstechnica.com/information-technology/2015/08/mozil...
I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.
I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.
Because in my view their problem wasn't about API versioning. They came out with a new version and deprecated the old, after all. It was that they provided way too much coverage early on.
Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.
Devs build apps that use APIs.
Users install apps that use APIs.
Users build their workflows around apps that use APIs.
Sometimes devs get bored/burn out/get a family/die/get a promotion, and stop building new features for apps. Sometimes, if users are lucky, they'll stay on top of security issues. But maybe, users install an app once and never update it even if it is getting updates. Which is risky, but if it works for them, whatever.
Service provider kills API endpoint.
App breaks.
User's workflow breaks. Worked yesterday, does not work today. :-(
Maybe, if the user is lucky, they connect with other users of the app, or users of other apps that are similarly affected, and they figure out workarounds, or someone creates a fork of the app(s) to use your new equivalent endpoint (if you even created one!) and, eventually, after much wailing and gnashing of teeth, they pick up the pieces of their workflow which you just broke and cobble together a new one.
But you caused them hours and hours of pain.
See also https://xkcd.com/1172/
The more attack surface, the better?
I absolutely agree -- starring repos should be a human act, not an automated one. No need for API exposure of this particular action.
Curbing automation is not a valid reason for its omission. I can reverse engineer the web page, figure out how it does it and implement it in a script if I want. People have done this to YouTube and Twitter, they can do it to GitHub too and there's absolutely nothing they can do about it.
How publicised and easy to use an API is is a different matter, which is why captchas are a thing. Though tbh, I hate captchas.