API for The 0cean

API.md

This API documetation has been moved to a public Github repository here

Good draft. A couple questions/comments.

• what is the primary difference between a GET to /order_book and /orders? They look to be querying the same set of data, albeit with different filters applied (via two separate sets of query parameters). Perhaps consider consolidating them?
• Querying for a specific order should be a GET to /orders/:orderhash rather than a query parameter
• POST to orders should return the order hash? I'm assuming that gets created when writing the order to your book
• will all open orders basically have an empty 'taker' field?

That's all I've got for now. Looking forward to this API!

Check the first comment in the code

[
front: [
  order :{
    price: ‘<>’,
    order : { //I think this is a TYPO and shouldn't be here. First there is no closing bracket of that and second  makes no sense to have order inside order.**
    exchange: '<>',
    maker: '<>',
    taker: '<>',
    makerToken: '<>',
    takerToken: '<>',
    feeRecipient: '<>',
    makerTokenAmount: '<>',
    takerTokenAmount: '<>',
    makerFee: '<>',
    takerFee: '<>',
    expirationTimestampInSec: '<>',
    salt: '<>',
    orderHash: '<>',
    ecdsa: { v: '<>', r: '<>', s: '<>' },
    amountRemaining: <0 to takerTokenAmount>
  },
  requiredFee : '<>'
},
……
],
back?: [/*<other side of book if applicable>*/]
]

Nice start! Some comments below:

1. Might be good to use same naming scheme for url fragments and parameters: e.g. if using order_book -> use token_pair as parameter rather than camel casing.
2. Are tokens guaranteed to not have ‘_’ in their name? I haven’t found any specification, so this may cause silliness down the road. Additionally, I think it might make sense to split this into 2 parameters (makerToken and takerToken) - which would solve this problem here.
3. Might want to allow priceWindow in % as well.
4. expirationTimestampInSec: Seconds might not be granular enough?
5. Generally, I suggest to follow REST conventions e.g. PUT /v0/orders/match or POST v0/orders/:order_hash/cancel
6. For PUT /v0/match - no errors detailed.
7. For POST /v0/cancel:
   a) The return value is just the amountCancelled. However, I may POST an array of orders to cancel, I think the return value should be of the same magnitude (array with each element contains order hash and amountCancelled). I would also add a bool there to say whether the order is now gone completely.
   b) Do you also want to allow amending the order ‘upwards’?
   c) Name of this method is could be misunderstood for cancelling orders.
   d) What are the semantics of sending request for an existing order but tokenAmount=0?
8. For GET /v0/asset_pairs:
   I think that when using names, only do this if it is meaningful in the context of the application or data. The names tokenA and tokenB returned in the response don’t seem to mean anything outside the context of the response. Consider returning this as an array with no named structures inside it. If an asset_pair describes a maker/taker relationship - why not call it maker and taker? If the asset_pair describes a 2-way maker/taker relationship - then how does this work?
9. In GET /v0/orders - the descriptions of the last 6 querystring parms is incomplete

Cheers!