You are viewing a single comment's thread from:
RE: 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?
So, this layer would actually sit in-between something like steem-js (which is a library for a specific language) and the
steemdAPI 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.