4 ms·

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

by k__ 2y ago

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.

penjelly 2y ago
> 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.
- Kim_Bruning 2y ago
  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.
alibarber 2y ago
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.
fidotron 2y ago
> 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.
freetonik 2y ago
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.
gollum999 2y ago
> 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.
- hahn-kev 2y ago
  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
- 01HNNWZ0MV43FF 2y ago
  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.
  - layer8 2y ago
    From the point of view of the server, the request might be a response. ;)
blackoil 2y ago
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.
- alibarber 2y ago
  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.
- netsharc 2y ago
  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?
01HNNWZ0MV43FF 2y ago
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.
- icedchai 2y ago
  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...
quectophoton 2y ago
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).

by k__ 2y ago

penjelly 2y ago

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

Kim_Bruning 2y ago
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.

alibarber 2y ago

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.

fidotron 2y ago

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

freetonik 2y ago

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.

gollum999 2y ago

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

hahn-kev 2y ago
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
01HNNWZ0MV43FF 2y ago
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.
- layer8 2y ago
  From the point of view of the server, the request might be a response. ;)

blackoil 2y ago

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.

alibarber 2y ago
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.
netsharc 2y ago
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?

01HNNWZ0MV43FF 2y ago

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.

icedchai 2y ago
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...

quectophoton 2y ago

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