>The first time you use such an API using a client which would handle all the payment stuff in the background, it would open a payment channel by depositing some amount in a smart contract with a standardized interface, a
and crypto is terrible way to deal with normal money transactions on every level
Crypto does have its problems, irreversible transactions can be a big problem. But with microtransactions, it might not matter that much.
I could imagine many more machine learning APIs popping up if it is created. Monetizing an API currently requires various third parties
> ~nobody wants to create something like this
Yes, because it would be a common good, for which there is no financial incentive for its potential creator - even if it would be a net positive for all once it is created
The root of the API service, example.com/api/ could GET a "service descriptor file", which describes all endpoints of the API, and the crypto address of the API provider. The first time you use such an API using a client which would handle all the payment stuff in the background, it would open a payment channel by depositing some amount in a smart contract with a standardized interface, and each subsequent HTTP GET to the chosen endpoint(s) would be supplied with a payment channel signature in its header (something like "X-Signature"), incrementally signing off on more transfers offchain.
The key to this would be to
(1) create a well-accepted payment channel contract
(2) create server and client side middleware that handles all this automatically
On the server side, something like https://www.hug.rest would be an ideal starting point, it automatically generates documentation in JSON format at the API root