5 ms·

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.

by pydry 4y ago

necovek 4y ago
In the modern web application architecture, a somewhat "static" frontend uses the API to talk to the backend, so an API is a requirement. 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.
ROARosen 4y ago
Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner. 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.
- mh- 4y ago
  Having seen some pretty deep npm trees, I worry what you're building could end up (accidentally) doing hundreds or thousands of stars. I'd be careful to not make it recursive, at least - only look at direct dependencies.
- pydry 4y ago
  Please dont. Your extension will probably get more people banned when they star 1200 repos.
- askiiart 4y ago
  Sounds cool, except that people will get banned. I'd recommend making a menu where people can click on individual dependencies to star, or have a button to star all (but with a very clear warning about the possibilty if getting banned).
  - ROARosen 4y ago
    Great idea! will keep in mind.
- wpietri 4y ago
  > the more API coverage a platform can provide the better 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/mozilla-sets-plan-to-dump-firefox-add-ons-move-to-chrome-like-extensions/ https://arstechnica.com/information-technology/2015/08/mozil...
  - ROARosen 4y ago
    >Every API endpoint is a promise, and it's also a constraint on future innovation. 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.
    - wpietri 4y ago
      Oh? If it's that easy, could you explain how you would have applied that in the Firefox case and avoided the massive problems they experienced? 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.
      - ROARosen 4y ago
        I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API. 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.
- AdrianB1 4y ago
  >> the more API coverage a platform can provide the better The more attack surface, the better?
quesera 4y ago
Upvoted to counter others' apparent misunderstanding of your comment. I absolutely agree -- starring repos should be a human act, not an automated one. No need for API exposure of this particular action.
- matheusmoreira 4y ago
  There absolutely is a need for API endpoints for every single feature present on the web application. What if someone wants to make their own custom client for GitHub? 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.
  - wpietri 4y ago
    Sure, people can do that. And people diving into janky private APIs know that they're taking a gamble, and that things may break at any time. That doesn't in any way oblige GitHub to support them.
KMag 4y ago
There are advantages to opening up all of the functionality of the web front-end as an API to allow alternative front-ends.

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.

by pydry 4y ago

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.

necovek 4y ago

In the modern web application architecture, a somewhat "static" frontend uses the API to talk to the backend, so an API is a requirement. 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.

ROARosen 4y ago

Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner. 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.

mh- 4y ago
Having seen some pretty deep npm trees, I worry what you're building could end up (accidentally) doing hundreds or thousands of stars. I'd be careful to not make it recursive, at least - only look at direct dependencies.
pydry 4y ago
Please dont. Your extension will probably get more people banned when they star 1200 repos.
askiiart 4y ago
Sounds cool, except that people will get banned. I'd recommend making a menu where people can click on individual dependencies to star, or have a button to star all (but with a very clear warning about the possibilty if getting banned).
- ROARosen 4y ago
  Great idea! will keep in mind.
wpietri 4y ago
> the more API coverage a platform can provide the better 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/mozilla-sets-plan-to-dump-firefox-add-ons-move-to-chrome-like-extensions/ https://arstechnica.com/information-technology/2015/08/mozil...
- ROARosen 4y ago
  >Every API endpoint is a promise, and it's also a constraint on future innovation. 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.
  - wpietri 4y ago
    Oh? If it's that easy, could you explain how you would have applied that in the Firefox case and avoided the massive problems they experienced? 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.
    - ROARosen 4y ago
      I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API. 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.
AdrianB1 4y ago
>> the more API coverage a platform can provide the better The more attack surface, the better?

quesera 4y ago

Upvoted to counter others' apparent misunderstanding of your comment. I absolutely agree -- starring repos should be a human act, not an automated one. No need for API exposure of this particular action.

matheusmoreira 4y ago
There absolutely is a need for API endpoints for every single feature present on the web application. What if someone wants to make their own custom client for GitHub? 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.
- wpietri 4y ago
  Sure, people can do that. And people diving into janky private APIs know that they're taking a gamble, and that things may break at any time. That doesn't in any way oblige GitHub to support them.

KMag 4y ago

There are advantages to opening up all of the functionality of the web front-end as an API to allow alternative front-ends.