Open roman-khimov opened 4 years ago
Supporting POST
in the oracle will cause the same data to be posted to the server multiple times. Because one request will be executed by multiple oracle nodes at the same time.
According to https://restfulapi.net/idempotent-rest-apis/
HTTP Method | Idempotent | Safe (no resource modification) |
---|---|---|
OPTIONS | yes | yes |
GET | yes | yes |
HEAD | yes | yes |
PUT | yes | no |
POST | no | no |
DELETE | yes | no |
PATCH | no | no |
Hence everything except POST and PATCH should be OK for most systems having idempotent semantics. For NeoFS, for example, PUT for already existing object will return success.
Maybe it will be better to support at least safe and idempotent verbs and let SC developer to decide if it's ok for his case to use particular method?
Supporting POST in the oracle will cause the same data to be posted to the server multiple times.
Yes. And in many cases it's just not a problem. I don't think anything has changed since https://github.com/neo-project/neo/pull/1243#discussion_r348365770.
Maybe it will be better to support at least safe and idempotent verbs
Agree.
Maybe it will be better to support at least safe and idempotent verbs
Agree.
The main part of the message was to let SC author to decide if it's ok to use POST in his particular case =) As most of http-based APIs rely on POST, it has to be available for SC author.
Smart contacts cannot write data to NeoFS without some level of support for POST, as I understand it. This is an important part of having fully decentralized, fully serverless dynamic Web 2.0 content. If you wanted to build e.g. a distributed Twitter, you would normally need to essentially build an attestation contract, have users upload content to NeoFS/IPFS, and have the hash pointing to said content stored on chain. But on-chain storage is expensive, and the growing size of storing the list of hashes would become expensive. There is no way for that SC/"server" to store that information off-chain. POST requests would allow this, and allow more broadly smart contracts to work as backends for (intelligently designed) frontends.
Otherwise, we should perhaps be more clear that Neo <-> NeoFS SC integration is intended to be read-only, as this is somewhat more limiting.
Summary or problem description At the moment Oracle contract only supports
request
method with URL and associated data that essentially allows to get something from the outside, but contracts also should be able to put/post/send something there. It's relevant both for NeoFS (Put operation) and HTTP (POST). Probably also for any other potential protocols that are to be supported.Do you have any solution you want to propose? At the very minimum we need some
send
method that could take arbitrary data and transmit it to the outside world returning the status of this operation to the callback.But there could be more functionality provided by various protocols (like Delete or Balance.Request for NeoFS, see #1270), so we need to also think about other potential extensions of the Oracle contract. It can be done by adding more methods to it, but maybe there is some better way to extend it,
Neo Version
Where in the software does this update applies to?