You are viewing a single comment's thread from:

RE: Designing a RESTful STEEM API

in #steem5 years ago

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.