HTTP is a network-based API
while re-reading Fielding's 2000 dissertation (again), i (re)discovered the section on "Architectural Lessons."
these lines jumped out at me:
What distinguishes the modern Web from other middleware [22] is the way in which it uses HTTP as a network-based Application Programming Interface (API).
...
A network-based API is an on-the-wire syntax, with defined semantics, for application interactions. A network-based API does not place any restrictions on the application code aside from the need to read/write to the network, but does place restrictions on the set of semantics that can be effectively communicated across the interface. On the plus side, performance is only bounded by the protocol design and not by any particular implementation of that design.
A library-based API does a lot more for the programmer, but in doing so creates a great deal more complexity and baggage than is needed by any one system, is less portable in a heterogeneous network, and always results in genericity being preferred over performance....
HTTP is the 'on-the-wire API.' that makes sense. and dealing with this kind of API is much more difficult (at first) for programmers who are accustomed to using 'library API' models. and this is also the reason most attempts to turn REST into a handy library API tend to fall down. they try too hard to be libraries. it's an understandable. i am proly doing the same thing my exyus web engine.
i need to keep a close on my code. and keep it to a bare minimum. i need to continue to support the 'network-based API.'