5 ms·

This is mostly a really long-winded promotion of the "Accept" header. The article's gripe about APIs is basically a gripe about poorly thought-out design in gen

This is mostly a really long-winded promotion of the "Accept" header. The article's gripe about APIs is basically a gripe about poorly thought-out design in general. Bad design isn't an artifact of the system in which you see it. Bad design exists everywhere. Keep APIs out of it. It's like saying that people should stop using cars because Lada keeps making fuel-inefficient outdated crap.

icebraining 13y ago
It's not just the Accept header. It's thinking less of APIs and more of hypermedia, which happens to be in a machine readable format. It's about creating the conditions for service-independent agents to discover and use new services, without having to be custom-coded to support them. Right now, we're doing the equivalent of having to extend the browser for each single site we want to access. Imagine that if Chrome users wanted to access HN, the browser had to have a "HN module" to interact with it. It's ridiculous, but that's where we're at with automated web agents.
- tbrownaw 13y ago
  An automated web agent isn't a replacement for a browser. It's a replacement for a browser plus person. And a person using a browser to access HN does need to learn how to interact with HN. This is helped somewhat if the person in question is familar with the general concepts used in web fora.
  - icebraining 13y ago
    Yes and no. Sure, the automated agents would need to perform some of the roles that are now performed by the user, but it's just one more layer: before, we just had text viewers, and all the formatting was interpreted by the users (add we still see in plain-text emails). Then came document viewers and that whole layer moved from the human to the machine. This is just one semantic layer above. And no, I'm not suggesting that were must build agent capable of human-like learning, that's why much like we had to transition from ad-hoc formatting marks to some kind of standard, we must also help our agents by tagging the information in our websites with standard marks. But the widespread conception of REST is actually an RPC architecture with more endpoints, and that's holding us back from building a smarter web.

icebraining 13y ago

It's not just the Accept header. It's thinking less of APIs and more of hypermedia, which happens to be in a machine readable format. It's about creating the conditions for service-independent agents to discover and use new services, without having to be custom-coded to support them. Right now, we're doing the equivalent of having to extend the browser for each single site we want to access. Imagine that if Chrome users wanted to access HN, the browser had to have a "HN module" to interact with it. It's ridiculous, but that's where we're at with automated web agents.

tbrownaw 13y ago
An automated web agent isn't a replacement for a browser. It's a replacement for a browser plus person. And a person using a browser to access HN does need to learn how to interact with HN. This is helped somewhat if the person in question is familar with the general concepts used in web fora.
- icebraining 13y ago
  Yes and no. Sure, the automated agents would need to perform some of the roles that are now performed by the user, but it's just one more layer: before, we just had text viewers, and all the formatting was interpreted by the users (add we still see in plain-text emails). Then came document viewers and that whole layer moved from the human to the machine. This is just one semantic layer above. And no, I'm not suggesting that were must build agent capable of human-like learning, that's why much like we had to transition from ad-hoc formatting marks to some kind of standard, we must also help our agents by tagging the information in our websites with standard marks. But the widespread conception of REST is actually an RPC architecture with more endpoints, and that's holding us back from building a smarter web.