Closed tuloski closed 6 years ago
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.
@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!
Sounds good, I'll take a stab.
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) :) .
See #812, current proposal is additive, does not modify or break current interface.
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.