API Theory

[nathanielhourt]

Implement new API machinery. Progress for this has already begun (ref #12) but there's a lot of improvement to be done.

There are three plugin types involved in API exposure:

• The plugin that defines the APIs and provides fc::api handles for them (i.e. chain_plugin)
• A plugin to configure exposure and handle API permissions (i.e. chain_api_plugin)
• Plugins that expose APIs to the outside world (i.e. http_plugin)

For example, chain_plugin exposes a RO and RW APIs. They are exposed as publicly-accessible fc::api objects. chain_api_plugin gathers up these APIs and wires them up with http_plugin. chain_api_plugin implements any necessary permissions/authentication mechanisms, so chain_plugin simply implements the API without caring about permissions, chain_api_plugin implements the permissions and determines which APIs get exposed where, and API exposure plugins like http_plugin make the API accessible to the outside world without concerning themselves with permissions.

[bytemaster]

I believe this is accurate, except that there is no need to expose it as an fc::api object, in fact it should just be a simple class that anyone can call given a pointer.

The fc::api can then use that simple class to define a generic interface that is implementation independent.

[nathanielhourt]

Also, all API calls take a single argument, a struct containing the parameters, and return a single value, a struct containing the results.

[bytemaster]

All APIs need to be documented throughly via doxygen in a manner that is easily accessible:

https://eosio.github.io/eos/group__eosiorpc.html

[heifner]

This issue has been complete for a long time. Although documentation could always be improved.