Skip to content
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

getOrderbook doesn't return all the book's info #799

Closed
tuloski opened this issue Sep 22, 2017 · 5 comments
Closed

getOrderbook doesn't return all the book's info #799

tuloski opened this issue Sep 22, 2017 · 5 comments

Comments

@tuloski
Copy link
Collaborator

tuloski commented Sep 22, 2017

Some fields returned by rippled are not returned by api.getOrderbook().
For example the "owner_funds" field which is fundamental to build autobridged books and the "flags" field.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@FredKSchott
Copy link
Contributor

FredKSchott commented Nov 13, 2017

Happy to take a stab at this with some direction. Mainly, where should this info live? Right now the object has format {specification, properties, state}, state feels like the best place to add.

Bigger picture, its a lot of extra work to create a separate data format for ripple-lib that's entirely different from the Ripple API, and the fact that its a smaller subset introduces bugs like this. Would you consider a format like this?

{
    "direction": "buy",
    "passive": true,
    "expirationTime": "1234567890",
    "makerExchangeRate": "365.9629780181032",
    "data": { /* Raw API Response Object */ }
}

Useful helper properties are still added but all API data is returned to the consumer (/w maybe some light formatting directly to taker_gets_funded/taker_pays_funded so that they expand strings to full objects). That way consumers don't need to learn a second less-documented API.

@intelliot
Copy link
Collaborator

@FredKSchott I'm in favor of returning all API data to the consumer, as you said. Historically, RippleAPI was designed independent of rippled. However, moving forward, we'd like to unify their APIs and make them as similar as possible. Please feel free to take a stab at this!

@FredKSchott
Copy link
Contributor

Sounds good, I'll take a stab.

@tuloski
Copy link
Collaborator Author

tuloski commented Dec 2, 2017

Yeah, I don't get why RippleAPI returns different structures from rippled. But if you change again you are gonna be hated by all developers (me included) :) .

@FredKSchott
Copy link
Contributor

See #812, current proposal is additive, does not modify or break current interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants