Could we add an easier way to call a function?

[treeder]

Rather than having to generate the hash for the data field on the client side, allow human readable input, like:

"call": {
  "function": "my_function",
  "args": [ "yo", 123 ]
}

Then rpc-proxy will convert that to the hash.

Or even better, something like this:

GET /contract/ADDRESS/FUNCTION?arg0=string:yo&arg1=int:123

Rationale

Say I have a simple app/webpage that wants to get data from a contract and display it, and I don't want to load in the full web3.js and create contract code just to get some data. I could just do a simple jquery.getJSON instead.

[jmank88]

We could expand #23 to make some method calls easier (never fully implemented path/query params), but isn't the ABI required to make contract function calls?

[jmank88]

We can't rely on query param ordering either.

Is it possible to import only web3.eth.abi?

import {AbiCoder} from 'web3-eth-abi';

const abiCoder = new AbiCoder();

[treeder]

Ordering: that's why I have arg0, arg1, etc. With their types which I think gives you everything you'd need.

Encoding docs are here: https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector

[jmank88]

It seems possible to do, but using web3-eth-api directly seems simpler and more flexible for users.

What format would we return data in?

[treeder]

Let's say I'm not using javascript, just want to curl and jq the data. It's essentially just making it easier to use eth_call which requires you to encode the data somehow and decode it in the response. Regular eth_call:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'

But I guess you'd have to know response types and order too... hmmm....

Let's use this example:

 "inputs": [
      {
        "name": "owner",
        "type": "address"
      }
    ],
    "name": "balanceOf",
    "outputs": [
      {
        "name": "",
        "type": "uint256"
      }
    ],

Example GET and response:

GET /contract/ADDRESS/balanceOf?in0=address:0xABC&out0=uint256
# returns:
{"response": [ 10000 ] }

[jmank88]

If the user is on the command line, isn't web3 a simpler choice? I don't see how we can avoid using the equivalent ABI data in some form, and having users manually specify it in their request seems unnecessarily cumbersome and error prone. Maybe there are some narrow use cases for simple functions though.

[jmank88]

Returning native JSON values instead of hex encoded values seems troublesome too.