Hacker News Reader

Comment by k__ | Hacker News Reader

Not a fan of these "old man screams at cloud" posts, but I had a similar experience.

Suddenly, everyone was talking about HTTP APIs, when they said API.

With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.

Now API is synonymous with HTTP.

Strange how things turn out in the end.

View on HN

> Suddenly, everyone was talking about HTTP APIs, when they said API.

I had a junior dev try to correct me when I used "framework" and "API" outside of a web context.

It caught me off guard at first, but the more I've thought about it, it seems inevitable as time goes on. The more abstractions we build, the more unreasonable it becomes to expect every developer to start with "bare metal" and work their way up. Schools are forced to teach with "the other side" (i.e. the highest-level abstractions) as the benchmark for graduating, because that's what employers need. So at some point they have to cut some of the more esoteric CS fundamentals and concepts to make room.

They did that before, it all depends on your definition of bare metal. They probably don't teach assembly, or circuit design even though that used to be bare metal

I had another dev mix up "object" and "response" and say "JSON response" in reference to a request that sent JSON. I asked 2 or 3 times, "Response to _what_?" before figuring it out. That still lives in my head.

From the point of view of the server, the request might be a response. ;)

Had a similar moment at one job. We were discussing possible API design choices for an integration project, and more than an hour into the meeting we realized half of the room was assuming HTTP. This rendered the majority of arguments spoken so far irrelevant.

There's even "REST API", that now means "RPC over HTTP using JSON".

I don't think I've ever seen anyone who describes their HTTP API as "REST" ever implement the HATEOAS part of the REST definition. And calling it REST without HATEOAS, is like calling a database ACID without Atomicity (for example).

> Suddenly, everyone was talking about HTTP APIs, when they said API.

I always try my best to delineate for people asking, but often I find they only care about the web API case, so me harping on about how an API can be used to control a robot OR a web server often just confuses them more.

I ... I may have made a web API that can control a robot?

Err.... I realize I'm not helping. I'll see myself out.

I had the same awakening a while back when changing industry. I was proud of my "API Design" that included header files, perhaps a python wrapper etc - whereas everyone else was talking about HTTP verbs, which luckily I was fairly well versed in.

Over the years I've come to like HTTP. It's mostly text-based, but you can send arbitrary binary data through it. The request-response pattern is a decent match for a world where most computers have no clue where they are, need help learning their own IP address, and are stuck behind trapdoor firewalls anyway, so the only really usable case is to reach out to a well-known server at a well-known address and ask it to do something.

Of the whole web stack, HTML is the only part I've consistently hated since the big web revolution that started around 2007. It's just such a piece of shit. JS got faster and TS redeemed it substantially. HTML still sucks.

The "big web revolution" started in the mid-90's. I think it started going down hill when JS and then CSS were thrown into the mix. That time (late 90's, early 2000's) would've been a good time to reassess if building "applications" on top of a document delivery system was really the right approach. Instead, we got workaround upon workaround, and now we have what we see today...

> With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.

Google, in particular, early on went for the php developer audience. Frankly this destroyed the technical credibility of people in the mobile space and we have been living with it ever since.

Because HTTP is ubiquitous and now performant enough. It has a whole ecosystem of battle tested tools that can handle any usecase you throw at it. So, unless you are writing an app used by billions of users or some game hyper-sensitive of latency or backend service for similar size platform, you'll do better with HTTP.

I think this comment misses what we're saying here in that there are many people working on things like operating systems, specialist desktop software and libraries, for whom API design has nothing to do with any form of network transport at all.

In my case, the company I worked at shipped a product that came with a set of header files and dynamically linked libraries that exposed some of the core functionality to the customers for use in their own software, and designing this API was a specific task in itself.

API stands for "application programming interface". E.g. a graphics card driver can provide an API for an application (a web browser, a game, a calculator app) to draw an image on your screen... should it speak HTTP to do that?

Reply on news.ycombinator.com