
Ask HN: Why don't people just stick to something universal for APIs? - VertexRed
Am I the only one that gets annoyed by varying methods used to contact API servers (XML-RPC, SOAP, REST...), not to mention that the output is usually in XML or JSON?<p>What&#x27;s wrong with having RESTful APIs, have all the API examples&#x2F;demos use cURL (I&#x27;ve yet to find a case where a cURL lacks a function for HTTP[s] requests) and finally have all the output in JSON?<p>Now this might be an unpopular opinion so feel free to shower me in downvotes.
======
niftich
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/](http://www.grpc.io/)

[2] [http://graphql.org/](http://graphql.org/)

------
bikamonki
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?

~~~
VertexRed
But RESTful APIs have been around for so long though, does this the existing
infrastructure situation really apply to this?

~~~
mattkrea
Of course it does. Every day I still deal with services that speak on a
schedule with SFTP and flat files.. existing infrastructure is hard to
eradicate.

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

~~~
VertexRed
Still I'm seeing fairly large services use things like XML-RPC to contact
their servers.

~~~
byoung2
Are these legacy services? I haven't come across anything recently that
doesn't use the json api/sdk pattern I described.

------
eip
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.

------
craigcabrey
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.

------
throwaway420
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.

~~~
VertexRed
That's usually the case, but I can't really come up with anything as I can't
find any downsides to it.

