-
Notifications
You must be signed in to change notification settings - Fork 11.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Endpoints GetObjects & GetObjectInfo #579
Conversation
sui/src/rest_server.rs
Outdated
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct Object { | ||
object_id: String, | ||
object_ref: serde_json::Value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit confused here--an object reference contains an ID. Will the ID be duplicated here, or is this the (version, digest) part of an object ref (in which case we might want to call it something else)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct I was duplicating the ID, fixed it to explicitly return ID/Version/Digest
*/ | ||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct GetObjectInfoRequest { | ||
owner: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In https://docs.google.com/document/d/1LYTRODgj5GuufocEqKTqzozJJ7MusFOK_s0f8JKoEaw/ (and I believe in the current CLI) the owner is optional. We should probably do the same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current implementation of the CLI (which the rest server uses) requires the owner field to get a client state. I will add a TODO here to change that. The documentation in PR#544 also reflects the correct behavior.
sui/src/rest_server.rs
Outdated
*/ | ||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct ObjectInfoResponse { | ||
owner: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think comments on these would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Full documentation will come with the merge of PR#544 but I will add the comments for these endpoints in this PR as well.
|
||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct Object { | ||
object_id: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the restrictions on the types that can appear in a Response
--e.g., could this be object_id: ObjectID
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just needs to derive Serialize
/Deserialize
and JsonSchema
. i.e. ObjectID
would need to derive from JsonSchema
and so would AccountAddress
and so on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha + makes sense. I would be in favor of adding these #derive(JsonSchema)
's everywhere instead of converting our Rust types into strings.
I did not know about this schemars
library that provides JsonSchema
--it is pretty nifty. Am wondering if we can express our SuiJSON
via a schema (not a priority, but could be useful for unifying JSON input/output formats in the future). CC @oxade for thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be great! I attempted to do this earlier but I started getting into the weeds with PublicKeyBytes/dalek
and I thought it was better to punt the idea. But now that SuiAddress
& PublicKeyBytes
are decoupled this may be easier? I will open an issue for this to either to derive from JsonSchema
or a custom SuiJsonSchema
// Need to use a random id because rocksdb locks on current process which | ||
// means even if the directory is deleted the lock will remain causing an | ||
// IO Error when a restart is attempted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @laura-makdah for visibility of cleanup conditions (relevant to an unrelated effort)
let get_objects_params = query.into_inner(); | ||
let address = get_objects_params.address; | ||
|
||
let wallet_context = &mut *server_context.wallet_context.lock().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huitseeker I am not sure exactly why I am able to borrow a mutable reference here without the macro complaining. The only difference is that I don't call an async function on client state (which is created from wallet context). Not sure if you see something I don't here.
|
||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct Object { | ||
object_id: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just needs to derive Serialize
/Deserialize
and JsonSchema
. i.e. ObjectID
would need to derive from JsonSchema
and so would AccountAddress
and so on.
sui/src/rest_server.rs
Outdated
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct Object { | ||
object_id: String, | ||
object_ref: serde_json::Value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct I was duplicating the ID, fixed it to explicitly return ID/Version/Digest
*/ | ||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct GetObjectInfoRequest { | ||
owner: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current implementation of the CLI (which the rest server uses) requires the owner field to get a client state. I will add a TODO here to change that. The documentation in PR#544 also reflects the correct behavior.
sui/src/rest_server.rs
Outdated
*/ | ||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct ObjectInfoResponse { | ||
owner: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Full documentation will come with the merge of PR#544 but I will add the comments for these endpoints in this PR as well.
|
||
#[derive(Deserialize, Serialize, JsonSchema)] | ||
struct Object { | ||
object_id: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha + makes sense. I would be in favor of adding these #derive(JsonSchema)
's everywhere instead of converting our Rust types into strings.
I did not know about this schemars
library that provides JsonSchema
--it is pretty nifty. Am wondering if we can express our SuiJSON
via a schema (not a priority, but could be useful for unifying JSON input/output formats in the future). CC @oxade for thoughts
Co-authored-by: Sam Blackshear <[email protected]>
Adds a few missing type constraints in the `KeyPair` trait, closes #579.
Adds a few missing type constraints in the `KeyPair` trait, closes MystenLabs#579.
This is the third of a series of PR's that will implement the client service API described as part of the GDC Eng Deliverables
The endpoints that are included in this PR are:
Get Objects: Return all objects owned by the account address.
curl --location --request GET 'http://127.0.0.1:5000/wallet/objects?address=2DB7987BD5F905EB8A257DD7090AADEA4D8839D9'
Get Object Info: Get object info.
curl --location --request GET 'http://127.0.0.1:5000/wallet/object_info?owner=2DB7987BD5F905EB8A257DD7090AADEA4D8839D9&object_id=4C0C061D0D386D65FC4FED1A31195A2D305389FC'