Everyone who's ever worked with JSON, check this out...
Spot the error in conventions....
So transactions is an array under results containing items 0-lasttransaction. OK.
....But then operations is an array under transactions containing always a single operation, identified by its operation type in the first entry in the array. It does parse, but there's no reason at all to have the first entry in the array be that. It could quite simply be an array with a single entry containing the operation type as the first field in the array. This, like a few other things in steem's data format, doesn't make much sense.
Errors (yes, errors!) like this filter down into every aspect of downstream work.
I've never seen a trasaction with more than one operation. Which then calls into question why we aren't just listing everything under transactions arrays-- each of the array-items under transactions could be a flat listing of facts. And this would indisputably:
- Save bandwidth
- Speed up processing
- reduce downstream workload
- make the API clearer
Now the last two items, they're important. Steemit SHOULD have an application ecosystem by now, but so far, there isn't much of one. I'm claiming that this is why. Now, it's not only this..... but fixing this would be a BIG step in the right direction.
If you submit a new post with "decline payout" option, you'll see it.
//Update:
IMO if we just simply "fix" it as you suggested, it will definitely break all the applications built on current API set (check http://steemtools.com/). Alternatively perhaps we can use the "version" field or so to identify clients with different JSON parsers.
I agree, update: versioning API updates would be useful...minor changes on API are expected at this stages...
Sorry, I shouldn't shit in the river. That is correct.
Also, good to know that edge case, but doesn't it make hella-more sense to eliminate edge cases (eg: comment_options)?
Think wider. The capacity of multiple operations in same transaction can bring many benefits, it's not only designed for
comment_options.Does it ever get used that way, though? And why wouldn't it work out to flatten whatever combinations you have in mind? (Or otherwise simplify them)
Check this for example: https://cryptofresh.com/tx/30aec8758e0891dc17af0f9a62522a3ed9a1863c
Or this https://steemd.com/tx/4f489ed39be8e402d36e666c7ce1321ee64f94c5
Some reasons/senarios:
comment_option)Steem isn't going to succeed by omitting the
[0]fromtransactions[0]['operations'][0]['type']from a developer perspective. IMHO being a developer is sometimes working with these limits / brainwaves from other devs, which might seem weird at first. Plus as said in previous comments, this array is actually in use and could well be used more in the future for different purposes.As @abit correctly stated, many current apps also take into consideration this array. Additionally i think we should follow the mantra: grow first, optimize later!
Nonetheless it would be great to keep a tracklog of desired api changes and once there will be a V2 in the making with breaking changes (while keeping the old one alive) these could be implemented.
Dare me to find out?
Hi faddat! I'm not sure what you mean :) I'm not native english... I run Steemtools btw, and made a couple of read-only steem-apps which almost all needed to take into account the array[0] with the operator :) Especially http://steemstream.com/
Challenge accepted.
Pls i dont understand what challenge i set? Thx :)
So now I am going to see what happens if you have steemit, and the API actually works.
I bet the site explodes. I bet it does become the data hub steemit thought it could be.
Arrays always make sense if there's even a chance their might be more than one in the future.
Classic example: an email property field on a contact. Most systems assume there will only ever be one email per contact. Later on if they want to make a change and allow for multiple emails, it breaks everything. If, on the other hand, they start with an array, people can just hard code "get me the first entry". If they later add more, those old clients still work as always while new clients can do something more intelligent. That's just one example. JQuery has used arrays for everything and it really simplifies things. It's all a matter of perspective. To call a design preference an error is a bit dogmatic. I'm glad to see some of the comments here explain possible future evolutions of how these arrays may be used.
Mostly, I'm concerned about unneeded complexity. That's the biggest thing here. But.... yes, you could call me quite dogmatic about that, and you'd be totally right.
Well there are more than 1 operations in transaction. (e.g. from top of my head, authoring and default voting goes to same transaction)
And I also think, the structure may not be optimal, but I like to believe it is structured for the long term and future scaling in mind...
......but what leads you to believe that?
This isn't a feature that helps people build on steem, so it's not going to help scaling.
Sounds like you are representing all people :P
Super-interesting! Now being flagged by what look to be zombies!
https://steemit.com/@rizwanali101
https://steemit.com/@jenniferlawrence
....or celebrities. I guess I'll let you be the judge on that one. Really I have no idea what's going on with @rizwanali101 or his partner @jenniferlawrence.
I wonder what happens next.
This post has been ranked within the top 50 most undervalued posts in the second half of Dec 15. We estimate that this post is undervalued by $7.40 as compared to a scenario in which every voter had an equal say.
See the full rankings and details in The Daily Tribune: Dec 15 - Part II. You can also read about some of our methodology, data analysis and technical details in our initial post.
If you are the author and would prefer not to receive these comments, simply reply "Stop" to this comment.