Topic: [Nxt] API of Nxt - page 6. (Read 37374 times)

guess those go on the wishlist for API2 - hey kids, don't unwrap your presents all at once 

but really: consider the potential of this stuff 

Current orders don't expire.

I wish I had thought of this when I submitted my list to CfB on requested asset exchange APIs.  maybe it can make it in.

hey CfB - sorry, this is going quite quickly.

Do you have 'getAccountAssets' call on your list? Sort of an inventory that lists which assets and how much of it an account has? Was mentioned before, just asking to make sure becasue it seems essential to me!

Aslo, there is the questions of conditional BUY/SELL offers: Can you make a BUY or SELL l
limit order, that has th efollowing properties:

1: the issuer can NOT revoke it
2: it expires at a certain point in time if it is not matched
3: it is coded to a SPECIFIC account OR to a SPECIFIC key, and only the owner of the account / holder of the key can execute it

I think it could be possible with the present NRS infrastructre, and this would provide an extremely powerful method to issue options on virtual assets.

ALSO: in certail combinations, this might allow schemes to implement SMART ESCROW - not sure yet, but there might be a way to do this.

Think of the utility value of these two things that can be done with options contracts!

I am just posing these here in case it goes too fast, but I'll also put it over to the API dev thread..
 

Check http://wiki.nxtcrypto.org/wiki/Nxt_API

Is there full documentation for API in one place?

I already implemented this API request. I'm waiting for other requests info to implement and release them. I don't have time to read all posts, could u guys cooperate and send me the "total" list?

Orders don't expire. Deadline means deadline of a transaction.

Posted this earlier in the main "messy" thread but will put it in here too:

______________________________________________________________
Issue:
I don't think the deadline in placing BID_ASK orders works.
I created some orders 2-3 days ago and they are still available. Then I created one today with deadline 5mins

Here is the API call
http://holms.cloudapp.net:6874/nxt?requestType=placeAskOrder&secretPhrase=PASSPHRASE&asset=2514416012262277241&quantity=888&price=88&fee=1&deadline=5

Result:
{"transaction":"15792899347256983572"}

here is the order
http://holms.cloudapp.net:6874/nxt?requestType=getAskOrder&order=15792899347256983572
Result:
{"price":88,"asset":"2514416012262277241","account":"4432258843260249105","quantity":888}

is it a bug? maybe deadline has another meaning if so can we have some sort of expiry of the Orders?

Also do you think we should be able to see the deadline (expiry time left) for the order when we do getAskOrder?

______________________________________________________________

Can we have an API that can return the asset qty owned by an account?
I am thinking in terms of our gateway. When we transfer asset to someone how can he then check he got the asset an API would be cool.

Depends on Jetty settings. I think it has a backlog.

so ... what does the NRS do when the client is sending queries faster than it can answer? discard them, or put them into a queue?

yes, I keep getting things like that also. first guess would be that it is s-t- related to the testnet ...

1. assetid 15328485893864579482
{"description":"ImagineFairness","name":"NEX","account":"16155265664111966451","quantity":1000000000}

2. askorder
http://holms.cloudapp.net:6874/nxt?requestType=placeAskOrder&secretPhrase=myphrase&asset=15328485893864579482&quantity=21&price=12&fee=2&deadline=8440

{"errorCode":6,"errorDescription":"Not enough funds"}

3. this is my balance
{"balance":1798600,"effectiveBalance":1798600,"unconfirmedBalance":1798600}

4.
use another assetid 14269709746849295412
return
{"errorCode":6,"errorDescription":"Not enough funds"} too

5.placebidorder
ok
{"transaction":"9414020448077975079"}

http://holms.cloudapp.net:6874/nxt?requestType=getAsset&asset=7849724807799454521

I think the 'bytes' part is s.t. else - the message as you sent it is accessible with its tTxId

MESSAGE SENT with apiCall:

https://192.168.178.24:7875/nxt?/nxt?&fee=1&secretPhrase=19letmyheartbestillamoment23&requestType=sendMessage&deadline=12&message=aaaaaaaaaaaabbbbbeeeeee1111&recipient=8208788471056955193

->message=aaaaaaaaaaaabbbbbeeeeee1111

transaction - 2440562297891784938
bytes - 0100a48a4f000c00390e4daf114f5628ed4d3cdb2f6dfbf41cc21c34b8c9bdca59a8fd612a84a63 b39f7ab559f79eb7100000000010000000000000000000000ca3153d90a91748d37b82eff79c5ef dd83e409d00d64c55d20414f1c3539e0029d6d96c690dd0a7075cd361e1baa0546ad75f21c95530 71642178b1d1710431c0d000000aaaaaaaaaaaabbbbbeeeeee111

                                                                                  in fact,  the message IS contained in 'BYTES' - interesting:   ^^^^^^^^^^^^^^^^^^



MSG RECVD on another account:

https://192.168.178.24:7875/nxt?/nxt?&requestType=getBlock&block=12844324000325204771

BLOCK:

payloadLength - 401
generator - 482115092852324318
transactions - [u'2440562297891784938', u'2896977874553576073', u'4889772855603033753']
timestamp - 5212956
numberOfTransactions - 3
previousBlock - 8946974642773827749
payloadHash - 15a5d862af5d1f65f6a905ff08fae9f2fa444c30c8cc9889993d346cd42652b1
baseTarget - 1532426424
version - 2
totalAmount - 1185
previousBlockHash - a520f6d4080a2a7c75a89a25a5267e8065e0ac1fab56fcca141bb4d9fd6d1dd4
height - 48473
blockSignature - 437d8ccf4bb1e6903cf877bfe6655c402ec0b100336cf1d224b74522d950cc0721793ea8da6697b 4c905a5a198be833003a34eb6263453289c8f39b7a89470b6
totalFee - 3
generationSignature - f233e37e16793f0a21f645da6e829220f6bfb561eb5690932ace4b68a38c500f



https://192.168.178.24:7875/nxt?/nxt?&requestType=getTransaction&transaction=2440562297891784938

Tx:

recipient - 8208788471056955193
fee - 1
sender - 8737506522730586553
timestamp - 5212836
senderPublicKey - 390e4daf114f5628ed4d3cdb2f6dfbf41cc21c34b8c9bdca59a8fd612a84a63b
subtype - 0
amount - 0
confirmations - 1
deadline - 12
attachment - {u'message': u'aaaaaaaaaaaabbbbbeeeeee111'}
signature - ca3153d90a91748d37b82eff79c5efdd83e409d00d64c55d20414f1c3539e0029d6d96c690dd0a7 075cd361e1baa0546ad75f21c9553071642178b1d1710431c
referencedTransaction - 0
type - 1
block - 12844324000325204771

Use getTransaction.

I have a question for our nxt GuiGurus here (cross post from main thread, which is meandering around a lot of other things) ..

I have the nxt api implementation for my nxTrader fairly well under control now, and I am working on the operations model of the client.

Please bear with my - I started late on this, only 1 week ago.

As I understand the nxt operations mode is as follows - please drop me a line if I have any misunderstandings there:


1 - information percolates through the network by the new blocks being generated (in rare cases they do not contain any transactions).

2 - when a new block is generated, it is broadcast through the network. the 'block' contains a bunch of metadata about itself, plus a payload. The payload is a list of transactions.

3 - a client is constantly on the lookout for new blocks. it does that by regularly polling an NRS server with the 'getState' query.
     the 'getSTate' query contains information about the network status, including the last block number. when that last block number changes from one poll to the next, that number will be the new block then.

4 - when that happens, the client has to 'getBlock' that new block, peel out the transactions therein, and analyze the transactions by type: 0,1,2 : transaction, messaging, coloredCoins, and subtypes. descritption of subtypes can be found with 'getConstants'.

5 - the client can do whatever it wants with the informaion about those transactions. it may disregard some, it displays different ones in different manners.

6 - the history of transactions is in the blockchain and transactions. also, the transactions for a specific account are always available via 'getAccountTransactionIds', so the client does not need to sift through    the whole history of the nxtNetwork every time it starts, it only needs to grab the transactions every time a new account number is entered.




Issue: I am (mostly) using a raspi to run my NRS. The raspi seems to have SIGNIFICANT problems to keep up with a polling freqency of even 1 second. I am using a QTimer - if I go to  something between 2 and 5 seconds, I don't have problem. But 1 second seems way too fast for the raspi, because it keeps returning only every 2 or three seconds (I have a clock that displays the time of return)


Questions:

1 - why does the raspi seem to have such problems with that?

2 - when I maintain that overload, i.e. query once per second: do the queries queue up and crash the raspi?

3 - this does not only concern the raspi: since I have a QTimer in my poll button, I can just as well query with  1 millisecond. If there is such an issue,  could I be able to bomb any NRS into oblivion with that?
    @CfB, Klee - would it make sense to test that on the testnet?

4 -  what exactly does the 'broadcastTransaction' do? if I 'sendMoney' , the transaction is sent into the network automatically, isn't it? so why (re?) - 'broadcastTransaction' ??

cheers,
l8orre

bug:cannnot locate the asset

step 1:
http://holms.cloudapp.net:6874/nxt?requestType=issueAsset&secretPhrase=myphrasez&amount=10&fee=1001&deadline=900&name=Dog&quantity=10
{"transaction":"14069547964793243165"}

so issue asset is ok

but
step2 :
getAssetIds don't contain 14069547964793243165
and getAsset
{"errorCode":5,"errorDescription":"Unknown asset"}

now i repeat step 1
{"errorCode":8,"errorDescription":"\"Dog\" is already used"}
 

know details about api, please visit here :
http://wiki.nxtcrypto.org/wiki/Nxt_API

I know this has been asked before but I can't find the answer. How do I retrieve AMs?

I sent myself an AM that reads "this is a test". Here: http://localhost:7874/nxt?requestType=getTransactionBytes&transaction=5483638297221124474

This returns:


However the "bytes" part has a bunch of stuff in the beginning that is not my message. How do I know where my message starts in "bytes"?

yes it does.  sorry for my herrrp and derrp