Viewing a response to: @anyx/designing-a-restful-steem-api
I'm a part-time steem dev, but I've missed the last 10-15 years of advancements in the technologies you talk about (REST for eg). So I'm not really sure how they work. But I use steem-js and rely on the promise behaviour of that API. Can you achieve asynchronous promise behaviour with this implementation of yours?
post_id | 76,635,729 |
---|---|
author | revo |
permlink | re-anyx-designing-a-restful-steem-api-20190619t032159032z |
category | steem |
json_metadata | {"tags":["steem"],"app":"steempeak\/1.12.2"} |
created | 2019-06-19 03:21:57 |
last_update | 2019-06-19 03:21:57 |
depth | 1 |
children | 1 |
net_rshares | 536,895,374,003 |
last_payout | 2019-06-26 03:21:57 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.238 SBD |
curator_payout_value | 0.079 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 320 |
author_reputation | 8,665,183,773,468 |
root_title | "Designing a RESTful STEEM API" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
anyx | 0 | 536,344,657,412 | 50% | ||
penghuren | 0 | 550,716,591 | 15% |
So, this layer would actually sit in-between something like steem-js (which is a library for a specific language) and the `steemd` API node chosen. If you're working at the library level -- you need not worry about the changes here, only whether or not steem-js would adapt to use this protocol rather than the json-rpc protocol it currently uses. At a library layer, one could absolutely implement the same functions and behaviour presented to the user -- like awaits or async promises. Think about it this way: it would not need to change the way steem-js presents itself to a user, it would change the way steem-js could talk to the back-end that is serving up the results. The layer I'm focusing on would make API nodes -- like api.steemit.com, or anyx.io -- much more effective at serving multiple applications and users all at the same time, regardless of if they use steem-js or steem-python or use an in-house solution. It's optimization in the middle.
post_id | 76,637,890 |
---|---|
author | anyx |
permlink | ptbvjj |
category | steem |
json_metadata | {"tags":["steem"],"app":"steemit\/0.1"} |
created | 2019-06-19 04:09:18 |
last_update | 2019-06-19 04:09:18 |
depth | 2 |
children | 0 |
net_rshares | 19,082,988,101 |
last_payout | 2019-06-26 04:09:18 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.000 SBD |
curator_payout_value | 0.000 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 964 |
author_reputation | 98,476,665,211,015 |
root_title | "Designing a RESTful STEEM API" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
revo | 0 | 19,085,890,793 | 30% | ||
scruffyjunkies | 0 | -2,902,692 | -100% |