Author Topic: Better API - Please Help Define It  (Read 2570 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

Better API - Please Help Define It
« on: November 24, 2015, 02:34:02 pm »
Everyone who wants a better API, please give us detailed description of what you want the API to be.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline monsterer

Re: Better API - Please Help Define It
« Reply #1 on: November 24, 2015, 02:39:43 pm »
HTTP access to all parts.

Exchanges need these functions:

* GetBlockHeight
* ListSinceBlock - especially important, to avoid jump through hoops as we do now
* GetBalance
* Send

Every transaction sending function should return a TXID immediately, which is then visible whenever that transaction turns up in future - and transaction must be queryable using this TXID at any time.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Xeldal

  • Guest
Re: Better API - Please Help Define It
« Reply #2 on: November 24, 2015, 03:51:37 pm »
Any time a balance or amount is returned it should be a consistent format (instead of sometimes strings sometimes integers)

Any time a balance or amount is returned it should be adjusted to the proper precision or the precision should be included(so multiple calls are not required)

When returning an order book, i'd like to see it separated in to an array of "bids": and an array of "asks": ideally ordered most to least relevant (standard for exchanges)

like monsterer mentioned access to all commands via http.  I believe its currently still not possible to cancel an order this way.

having a separate call for placing a bid and placing an ask that accepts the standard fields "price" and "amount" instead of the current "amount" and "minimum amount expected"  (it works just fine and makes sense as it is with just 1 call but its not the standard way of doing it.)

in the return from get balances, it would be nice to have for each asset an "amount_in_orders" value

with the exception of access to cancel_order and other http requests, all the above have work arounds, just suggesting for simplicity and similarity to other exchanges.

TravelsAsia

  • Guest
Re: Better API - Please Help Define It
« Reply #3 on: November 24, 2015, 04:48:36 pm »
The ability to automatically return funds if a minimum amount isn't reached. Think Kickstarter.

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
Re: Better API - Please Help Define It
« Reply #4 on: November 24, 2015, 05:16:17 pm »
Basically what we need is to be able to access the wallet from a 3rd trading platform.

1.  Need to receive "tick" data (this is the last reported price and volume for an asset).  We need to take these "ticks" and create price charts with them.
2.  Need to be able to access the exchange from the 3rd party platform.  This includes account data such as open positions balances.
3.  The platform needs to be able to create and send orders to the DEX on behalf of the user.  The dex needs to be able to take this command and execute the order.  The dex will need to be able to accommodate limit and stop orders on the block chain level.
« Last Edit: November 24, 2015, 05:36:33 pm by lil_jay890 »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12915
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Re: Better API - Please Help Define It
« Reply #5 on: November 24, 2015, 05:29:03 pm »
Another list of feature requests:
https://github.com/cryptonomex/graphene/issues/382

Thanks for considering to improve the API!!! +5%
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline roadscape

Re: Better API - Please Help Define It
« Reply #6 on: November 24, 2015, 06:03:35 pm »
 - get_market_history via RPC & in the CLI wallet appears to return the first 200 buckets, not the most recent 200 buckets.

 - Consistency in returning object ids from the API - tx's, ops, accounts, etc. Ideally whenever an object is returned, its id is included.

 - More/bigger batch methods. Until the API is more fleshed out, simply making it easier to pull data in bulk from witness_node can really help fill in the gaps. e.g.:
   - get_account_history - ideally could return more than 100 items
   - get_full_blocks(start, limit) - would be nice to have this. blocks can only be pulled 1 at a time

 - Returning virtual ops where expected (get_block?). Many virtual ops are only seen in get_account_history, and never show up in get_block

 - Governance features: important for this data to be as rich as possible.. for example, the ability to query how much a worker has been paid *in total*. Currently we can only pull the "un-withdrawn" balance object.

 - Would be nice if proposals were not removed from the db, until we get the plugin architecture for this stuff. And to be able to see if a proposal was in actually approved or not, after the fact.

I could come up with a lot of "nice-to-haves" but in the short term just exposing as much data as possible helps a lot.
http://cryptofresh.com  |  witness: roadscape

Offline wackou

Re: Better API - Please Help Define It
« Reply #7 on: November 24, 2015, 06:33:33 pm »
There's this also:

https://github.com/cryptonomex/graphene/issues/339

I am actually going to submit a pull request for it (hopefully tonight) for the first 3 ones.

The last one (blockchain_get_witness_slot_records) required some sort of optional indexing in bts1, and I'm not sure it is implemented in graphene. A workaround (for me) would be to allow to query blocks in batch, as suggested by roadscape, and/or have a way to know which block was produced/missed by a witness.
Please vote for witness wackou! More info at http://digitalgaia.io

Offline monsterer

Re: Better API - Please Help Define It
« Reply #8 on: November 25, 2015, 10:00:20 am »
Oh yes - another point:

*) Make a single point of entry into the system for API calls, rather than having the API commands duplicated (but with different functionality) between the cli_wallet and the witness_node.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline wackou

Re: Better API - Please Help Define It
« Reply #9 on: November 25, 2015, 02:48:20 pm »
Please vote for witness wackou! More info at http://digitalgaia.io

TravelsAsia

  • Guest
Re: Better API - Please Help Define It
« Reply #10 on: November 25, 2015, 02:59:54 pm »
I'm not sure if this is an API improvement or something that is already there but not accessible from the wallet. It would be nice to make cold storage simple.

Offline theoretical

Re: Better API - Please Help Define It
« Reply #11 on: November 25, 2015, 03:46:32 pm »
I'd like to allow plugins to define API calls, and configuration file options to specify which plugins to enable, and which plugins require login to access their API calls.

  • It allows us to break the API up into smaller units.  Currently database_api is huge because we have to put everything accessible without login in there.
  • It allows a path for API upgrade.  If the old API and new API are plugins which can be enabled / disabled by a specific site, then a site can upgrade the API on their schedule, not ours.
  • It allows different security profiles.  For example, we could create a "HTTP plugin" which makes login and secure API calls of other plugins accessible over HTTP.  Sites that want to interface with the wallet over HTTP can use that plugin (and then it is on them to ensure the wallet is properly firewalled, containerised or otherwise isolated), while the default config has the plugin disabled for security reasons.

Related issues:  #245, #246, #422.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Re: Better API - Please Help Define It
« Reply #12 on: November 25, 2015, 04:13:11 pm »

I also think the new API should have a single object type for input and output, and do input parsing and output annotation by reflection.

For example:

  • On the input side, we want API to accept an asset name wherever we accept an asset ID.
  • On the output side, whenever an asset is returned by API, we return a 3-field object of the form {"sym" : symbol, "prec" : precision, "amount" : x}

We currently accomplish this by requiring each asset method to take asset as a string and then manually call parsing functions.  Which is done inconsistently.

A better approach is to have every API call take an input struct, then use reflection to find any (potentially deeply nested) JSON fragment of the incoming object which has an asset_id_type, essentially moving the responsibility to parse asset ID's from the API method to the API framework (where "API framework" means some new, Graphene-specific glue code, as it will have to be aware of chain_db).

Likewise, output annotation requirements like the second requirement above can be handled similarly:  Any place the output object has an asset_id_type, the framework automatically annotates it with the name and precision of the asset.  Or possibly instead fills in a secondary "asset LUT" in the response containing such information for all assets (which makes the response smaller).

Accounts could obviously similarly benefit.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Re: Better API - Please Help Define It
« Reply #13 on: November 25, 2015, 04:20:16 pm »

Also on my wishlist for the API:  Generate a JSON blob representing full type information for each API call, which can be used to auto-generate language bindings for the API.

You can think of this as like splitting James's JSON operation serializer into a frontend which reflects all Graphene types, and a backend which outputs various useful JS code, such as a JS class for all C++ structs.  The frontend would then output a JSON blob which is taken by the backend.

I'm pretty sure JS language object model is sufficiently powerful that the backend could be completely written in JS as a generic library, which would take the JSON blob and construct the classes at runtime.  Python could be done similarly.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Re: Better API - Please Help Define It
« Reply #14 on: November 25, 2015, 04:32:34 pm »
Make a single point of entry into the system for API calls, rather than having the API commands duplicated (but with different functionality) between the cli_wallet and the witness_node.

I think what needs to happen is that API calls need to be automatically forwarded from the cli_wallet to the witness_node.

This ties into my previous points, it's better if we have ways to refer to API methods, or groups of API methods, in a config file, so we'd be able to configure enabling/disabling this forwarding on a per-call or per-API basis.  And if the cli_wallet can ask the witness_node for type information on all API methods it supports, then it can improve the forwarding, even if the cli_wallet is not implemented in the same language as the backend.

Which leads me to the next item on my wishlist, writing a cli_wallet in Python so you can use proper scripting instead of the very clunky transaction_builder for creating proposed transactions, but that's sort-of off-topic.  There's a lot I'd want to do to improve Graphene -- doing it all would probably take a year or two and several junior devs.
« Last Edit: November 25, 2015, 04:35:30 pm by theoretical »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk