|
|
|
|
|
|
by krsyoung
3711 days ago
|
|
|
You blew my mind a little bit there ... so you're introducing the notion of a super light-weight subscription / payment system to sidecar the API specification itself? This something that would make sense with state-less services vs those requiring some investment by the service provider (i.e. some account with more backend overhead)? Having the API specification cover more of the business/service aspects is very interesting (could you possibly define cost per call per endpoint or per payload size for instance). |
|
|
The only costs that would occur would be transaction fees for changing state in the Ethereum network (which is only required once for registering the service and at the order of half a cent at the current scalability level) and a similar amount for opening and closing the payment channels. I'm currently implementing a prototype extending http://hug.rest. If executed correctly, the following three lines of Python:
@hug.get("/pay_world", requires=pay("$0.001")) def pay_world(): return "You paid for this"
would result in the framework generating the OpenAPI spec amended with the payment metadata in the background and making it available under the service root. A middleware layer would check every ingoing request for payment signatures, closing the payment channel if necessary. Interesting things would become possible, although it is not clear if it all will succeed. Many different kinds of payment mechanisms would be conceivable, from pay-per-call to subscription based. Hypothetically, you could even pay APIs with gold backed cryptocurrency or tokens you issued yourself.
See here for a similar project and reasoning: https://github.com/etherapis/etherapis