3 ms·

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interfa

by SilasX 4y ago

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

recursivedoubts 4y ago
REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). Generic Data APIs, and the clients that use them, are different and have different needs.
- SilasX 4y ago
  >REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). No, the interpretation is done by the human using the browser, which is what makes it not programmable against, violating the P in the acronym.
  - recursivedoubts 4y ago
    The brower, a hypermedia client, sees the links, for example, in the API responses and renders them for the human to interact with. The browser is a hypermedia client, working against a hypermedia API. It not understanding the content of the responses beyond the hypermedia layer is by design: that's the uniform interface of REST. I mean, this is quibbling over definitions. I agree entirely with your general point that REST hasn't worked out well as a network architecture for non-hypermedia clients.
Aeolun 4y ago
You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.
- SilasX 4y ago
  Right. But the issue wasn’t whether you can interface with one via other applications, but whether you can do so while adhering to the REST principles Fielding gave, which require that you not have any context to interpret a response other than the response itself. So no out-of-band communication like documentation or your previous use or the site. At that point, you do need a human at each point, and you can’t program against it. Programmatically interacting involves precisely the things REST principles prohibit, hence this point in the discussion.

by SilasX 4y ago

recursivedoubts 4y ago

REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). Generic Data APIs, and the clients that use them, are different and have different needs.

SilasX 4y ago
>REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). No, the interpretation is done by the human using the browser, which is what makes it not programmable against, violating the P in the acronym.
- recursivedoubts 4y ago
  The brower, a hypermedia client, sees the links, for example, in the API responses and renders them for the human to interact with. The browser is a hypermedia client, working against a hypermedia API. It not understanding the content of the responses beyond the hypermedia layer is by design: that's the uniform interface of REST. I mean, this is quibbling over definitions. I agree entirely with your general point that REST hasn't worked out well as a network architecture for non-hypermedia clients.

Aeolun 4y ago

You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.

SilasX 4y ago
Right. But the issue wasn’t whether you can interface with one via other applications, but whether you can do so while adhering to the REST principles Fielding gave, which require that you not have any context to interpret a response other than the response itself. So no out-of-band communication like documentation or your previous use or the site. At that point, you do need a human at each point, and you can’t program against it. Programmatically interacting involves precisely the things REST principles prohibit, hence this point in the discussion.