Add rest server support for wasm module, to query and create tx #7

ethanfrey · 2020-01-08T15:20:07Z

Summary

We only have CLI, and we will want to add support for a rest server. This would go into x/wasmd/client/rest and be exposed with the standard wasmcli rest server.

Problem Definition

We want to allow webapps to do everything we can do in the CLI. I have no clear design for the urls, so the first part is maybe to propose a set of endpoints. I want queries and ability to submit the 3 tx defined in this module. This will be the basis for a js api.

This will also probably involve refactoring the Querier a bit to allow better reuse between cli and rest.

Proposal

To be filled in (add your proposal of endpoints in the comments, please)

For Admin Use

Not duplicate issue
Appropriate labels applied
Appropriate contributors tagged
Contributor assigned/self-assigned

The text was updated successfully, but these errors were encountered:

sahith-narahari · 2020-01-12T08:09:23Z

I feel endpoints should be grouped separately for code and contract. Here is the list of endpoints I think should be good. I wanted to make sure they don't deviate much from client.

Transactions:

POST /code/store
POST /contract/Instantiate
POST /contract/Execute

Query:

GET /code/list
GET /code/query
GET /contract/list
GET /contract/info
GET /contract/state

alpe · 2020-01-13T13:36:20Z

@sahith-narahari can you elaborate on the reason for the code - contract separation please?
IMHO their lifecycles are related. There can not be any contract instance without the code. Neither should we delete a code entry and keep an instance running for example.

I would propose the following endpoints with json body for non query operations:

Create Contract

POST `/wasm/contract`

Requires:

Sender
WASMByteCode

Returns:

Code: 201 - Created
Body: codeID - unique identifier
Header: Location: /wasm/contract/<codeID>

Create Instance

POST `/wasm/contract/<codeID>`

Requires:

Sender
InitMsg (or should be optional?)
InitFunds (or should be optional?)

Returns:

Code: 201 - Created
Body: ContractAddr - unique sdk address
Header: Location: /wasm/contract/<ContractAddr>

Execute contract

POST `/wasm/contract/<ContractAddr>`

Requires:

Sender
Msg
SentFunds (or should be optional?)

Returns

Status: 200 - OK
Body:
- Data: contract result data
- Log: contract result log
- GasUsed

Future endpoints ?

DELETE `/wasm/contract/<ContractAddr>`

Requires:

Sender

Returns:

Code 200

ethanfrey · 2020-01-13T13:44:45Z

Thank you both for your comments.

In general, the list looks correct for scope @sahith-narahari And I do agree (to 95%) with the detailed version from @alpe , thanks for spec'ing this more. It does look more RESTful,

The one issue with the second part is the confusion between /wasm/contract/<codeID> and /wasm/contract/<ContractAddr>. We cannot have two identical endpoints with different functions. I would make it:

POST /wasm/code -> create code
POST /wasm/code/<codeID> -> instantiate code (from one instance, returns contract instance)
POST /wasm/contract/<contractAddr> -> execute one contract

The DELETE is interesting, but very unlikely ever to be used (immutible contracts and all), however, there is a request for upgradable contracts, so we'll see...

ethanfrey · 2020-01-13T13:49:15Z

Sticking with that pattern, I would make the queries more "RESTFUL":

GET /code/ -> list all code IDs
GET /code/<codeID> -> details of one code ID
GET /contract/ -> list all contracts addresses
GET /contract/<contractAddr> -> info on one contract
GET /contract/<contractAddr>/state -> internal state of one contract

I am unsure about code/contract vs codes/contracts, maybe the plural is more common in rest? But I do like consistency, not /contracts to list and /contract/<addr> for details.

And all cli flags we want to support should be turned into query args ?foo=bar style.

What do you think here?

sahith-narahari · 2020-01-13T13:58:58Z

Thanks for the detailed explanation @alpe @ethanfrey. My main motto behind the separation was ListCode and ListContract will create an ambiguity with same endpoints.
I agree the better solution would be to separate only the query list APIs and maintain all the other endpoints as /wasm/contract consistently.

sahith-narahari · 2020-01-13T14:01:10Z

Regarding contract/contracts I'm also in favor of using singulars to maintain consistency across various requests

workshub · 2020-01-13T14:41:53Z

This issue is now published on WorksHub. If you would like to work on this issue you can
start work on the WorksHub Issue Details page.

alpe · 2020-01-13T14:43:29Z

Sorry about the ambiguity in the path of my proposal. I was doing some edits before submitting. It was like this before:

Instance
POST /wasm/code/<codeID>/instance
Execute
POST /wasm/code/<codeID>/instance/<ContractAddr>

This reflects the dependency between code and contract in a REST-ish style but for execution the caller would need to know or resolve codeID and contractAddr. That may not be very convenient.
@ethanfrey your proposal is a good compromise.

workshub · 2020-01-13T18:01:36Z

@sahith-narahari started working on this issue via WorksHub.

ethanfrey · 2020-01-13T19:48:25Z

Please note that #12 changes the contract state querier, so don't implement that part until #12 is merged and rebase on the new master

sahith-narahari · 2020-01-14T07:05:03Z

Thanks @ethanfrey for the heads up, will ensure that.

sahith-narahari · 2020-01-19T18:27:54Z

@ethanfrey I'm done with all functions except for contract state. I see in cli it was separated using sub-commands, how would you like me to go ahead with this in rest.

ethanfrey · 2020-01-19T19:22:35Z

Hi @sahith-narahari can you make a pr with the current state. I would be happy to merge this while work continues, so I can start to test out on a live node.

As to the state query functions, I would us a separate path for each.

/contract/<contractAddr>/state - all
/contract/<contractAddr>/smart - smart query
/contract/<contractAddr>/raw - raw query

If you have better names, you can use those instead

sahith-narahari · 2020-01-19T19:39:20Z

Thanks, will raise a PR with current state

ethanfrey · 2020-01-20T10:05:46Z

I merged this PR.
Mainly missing two query functions (raw and smart queries on contract state).
And some tests on it would be nice - if nothing else to demo usage.
(But it seems there is no way to test this properly in cosmos-sdk???)

sahith-narahari · 2020-01-20T10:31:21Z

Yes, I will the add remaining two query functions.

Even I wanted to test these, will try to find a way. Else I'll test them manually by deploying a contract using rest and query it

ethanfrey · 2020-01-20T13:36:27Z

A manual test is better than no test at all. And good enough for now. If it works, the tests are there to keep us from breaking stuff in the future. Which we can do once we figure out a good approach (consulting cosmos-sdk core team on best practices)

* Update to ibc version of wasmvm * Update test contracts * Adjust code to updated wasmvm * Update to tip of wasmvm PR 172 * Update test contracts and add stargate support to tests * Upgrade to wasmvm 94043576bb71 Co-authored-by: Alex Peters <alpe@users.noreply.github.com>

…s/github.com/cosmos/ibc-go/v2-2.0.2

jsoneaday · 2023-01-16T22:21:25Z

Is there an official doc for the rest paths? It's not clear which style got accepted

alpe · 2023-01-17T10:58:13Z

The REST integration was deprecated and is removed now. Instead there is a grpc-rest gateway endpoint. You can see the path defined in in the query proto file

…osmWasm#7) * featremove custom proto changes of genesis and types * feat!: extract custom wasm logic for lbm-sdk * feat: move custom cli of lbm-sdk to `wasmplus` client package * feat: remove params for wasmplus. just use original params of x/wasm * chore: remove unused customEncoding and customQuerier * chore: apply a changes about separated ibc-go import path * doc: add readme of `x/wasmplus` * fix: lint error * chore: add more unittest * chore: add more unittest * chore: add more unittest * chore: add more unittest * chore: update changelog * chore: remove interchain-accounts * chore: feedback reviews * doc: update proto changes * chore: apply review feedback - move all function of `wasmplus/keeper/keeper_extension.go` to `wasmplus/keeper/keeper.go` - remove no need files (keeper_extension.go, metrics.go)

ethanfrey mentioned this issue Jan 8, 2020

Upgrade to cosmwasm 0.7 #5

Closed

7 tasks

ethanfrey added the API Fixes to the external client api label Jan 10, 2020

sahith-narahari self-assigned this Jan 12, 2020

sahith-narahari mentioned this issue Jan 19, 2020

Added rest interface #30

Merged

5 tasks

sahith-narahari mentioned this issue Jan 23, 2020

Added contract state query to rest #45

Merged

5 tasks

ethanfrey closed this as completed in #45 Jan 23, 2020

giansalex pushed a commit to disperze/wasmd that referenced this issue Dec 17, 2021

Merge pull request CosmWasm#7 from notional-labs/dependabot/go_module…

eb870df

…s/github.com/cosmos/ibc-go/v2-2.0.2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add rest server support for wasm module, to query and create tx #7

Add rest server support for wasm module, to query and create tx #7

ethanfrey commented Jan 8, 2020 •

edited

sahith-narahari commented Jan 12, 2020

alpe commented Jan 13, 2020 •

edited

ethanfrey commented Jan 13, 2020 •

edited

ethanfrey commented Jan 13, 2020

sahith-narahari commented Jan 13, 2020

sahith-narahari commented Jan 13, 2020

workshub bot commented Jan 13, 2020

alpe commented Jan 13, 2020

workshub bot commented Jan 13, 2020

ethanfrey commented Jan 13, 2020

sahith-narahari commented Jan 14, 2020

sahith-narahari commented Jan 19, 2020

ethanfrey commented Jan 19, 2020 •

edited

sahith-narahari commented Jan 19, 2020

ethanfrey commented Jan 20, 2020 •

edited

sahith-narahari commented Jan 20, 2020

ethanfrey commented Jan 20, 2020

jsoneaday commented Jan 16, 2023

alpe commented Jan 17, 2023

Add rest server support for wasm module, to query and create tx #7

Add rest server support for wasm module, to query and create tx #7

Comments

ethanfrey commented Jan 8, 2020 • edited

Summary

Problem Definition

Proposal

For Admin Use

sahith-narahari commented Jan 12, 2020

Transactions:

Query:

alpe commented Jan 13, 2020 • edited

Create Contract

POST /wasm/contract

Requires:

Returns:

Create Instance

POST /wasm/contract/<codeID>

Requires:

Returns:

Execute contract

POST /wasm/contract/<ContractAddr>

Requires:

Returns

Future endpoints ?

DELETE /wasm/contract/<ContractAddr>

Requires:

Returns:

ethanfrey commented Jan 13, 2020 • edited

ethanfrey commented Jan 13, 2020

sahith-narahari commented Jan 13, 2020

sahith-narahari commented Jan 13, 2020

workshub bot commented Jan 13, 2020

alpe commented Jan 13, 2020

workshub bot commented Jan 13, 2020

ethanfrey commented Jan 13, 2020

sahith-narahari commented Jan 14, 2020

sahith-narahari commented Jan 19, 2020

ethanfrey commented Jan 19, 2020 • edited

sahith-narahari commented Jan 19, 2020

ethanfrey commented Jan 20, 2020 • edited

sahith-narahari commented Jan 20, 2020

ethanfrey commented Jan 20, 2020

jsoneaday commented Jan 16, 2023

alpe commented Jan 17, 2023

ethanfrey commented Jan 8, 2020 •

edited

alpe commented Jan 13, 2020 •

edited

POST `/wasm/contract`

POST `/wasm/contract/<codeID>`

POST `/wasm/contract/<ContractAddr>`

DELETE `/wasm/contract/<ContractAddr>`

ethanfrey commented Jan 13, 2020 •

edited

ethanfrey commented Jan 19, 2020 •

edited

ethanfrey commented Jan 20, 2020 •

edited