Re:U.S. House committee approves blueprint for Big Tech crac...
by mindslight on Sunday April 18, 2021 @04:20PM
(#26855950)
> Front and back end teams work together to make changes and don’t have to maintain a stable API for any other consumers.
So you agree that they already have to maintain stable APIs for each other? Meaning the mandate would be just adding a requirement for external visibility into the existing internal process, not anything significantly different from what they're already doing.
> If I was interviewing someone for a technical role and they told me that APIs were like charging connectors, I would say ‘no hire’, and complain to the recruiter.
So are you closed minded to analogies in general, don't appreciate that the physical layer has its own complexity, or what? The same type of arguments you're making were also levied at micro USB, by companies trying to keep their bespoke proprietary connectors so they could charge $50 for a spare phone charger. In the end they lost and the market benefited.
> Your argument seems to be that supporting external API clients in addition to an in-house UI imposes no burden
I agree there's a "burden". It's a small burden. One easy bound on this burden is that it is much less effort than developing a mobile app or another whole website specifically for mobile users. And most companies have eagerly done both.
> If you could accept that there are architectural constraints imposed by your demand
You keep using this word architecture. The current de facto deliverable includes XML or JSON documents. The deliverable for the mandate would be differently-formatted XML or JSON documents. Calling a second formatting an "architectural constraint" is a stretch.
So you agree that they already have to maintain stable APIs for each other? Meaning the mandate would be just adding a requirement for external visibility into the existing internal process, not anything significantly different from what they're already doing.
> If I was interviewing someone for a technical role and they told me that APIs were like charging connectors, I would say ‘no hire’, and complain to the recruiter.
So are you closed minded to analogies in general, don't appreciate that the physical layer has its own complexity, or what? The same type of arguments you're making were also levied at micro USB, by companies trying to keep their bespoke proprietary connectors so they could charge $50 for a spare phone charger. In the end they lost and the market benefited.
> Your argument seems to be that supporting external API clients in addition to an in-house UI imposes no burden
I agree there's a "burden". It's a small burden. One easy bound on this burden is that it is much less effort than developing a mobile app or another whole website specifically for mobile users. And most companies have eagerly done both.
> If you could accept that there are architectural constraints imposed by your demand
You keep using this word architecture. The current de facto deliverable includes XML or JSON documents. The deliverable for the mandate would be differently-formatted XML or JSON documents. Calling a second formatting an "architectural constraint" is a stretch.