Ask HN: Why don't people just stick to something universal for APIs?

They do stick to trends.

The problem is, trends change over time. Back in the early 2000s, SOAP was The Orthodox Way lest you got shunned. In the early 2010s it was HTTP-based templated URLs, JSON payloads usually served as "application/json" documented out-of-band, secured with OAuth 2.0 increasingly in favor of other methods. The future is undecided, but new RPC frameworks are being embraced (RPC is no longer a dirty word) [1], and some people are even re-inventing the idea of passing an actual query written in a query language from client to server [2].

So, in short, new ideas come along; sometimes new ideas are a re-imagining (or lessons learned) of old ideas. Factors involved in engineering trade-offs change; and finally, some of it is simply fashion.

[1] http://www.grpc.io/

[2] http://graphql.org/

Simple: existing infrastructure. Just as phasing out petrol-powered vehicles will take decades, so it takes years to move IT infra to the new standards. Add to it this complexity: new ways to solve IT problems arise all the time. Just as now it seems that REST + JSON are the best possible solution, SOAP + XML had the same status a few years back. What will happen when browsers run byte code? Or when we descentralize internet services?

I think the current trend is a rest api with json input/output, and an sdk in the popular languages that wraps the api.

REST and JSON are inefficient and irritating to work with. Websocket with binary protocol like protobuf is much nicer. Even SOAP was much nicer because you could usually code generate a client from a WSDL.

Because having a one size fits all mindset is a narrow view to hold.

Use cases should drive engineering decisions, not a grand vision of the world in someone's head.

I think we've all been there before...wouldn't it be nice if there was one standard way of doing something?

Yes and no.

Sure, it might make things easier most of the time.

But a one-size-fits-all approach might also lead to limited innovation and experimentation.