API Definitions Decorator Properties

[inertia186]

"As a devportal team member, I want to label an api definition, so that the fancy labels show up on them and look fancy."

Previously (#118), on devportal, I added broadcast operations. During the process of researching the 35 or so operations, I was able to dig into the history of them. For example, the liquidity_reward operation looks like this:

The rest of API Definitions can benefit from having these labels as well.

For since:, use the format since: HF14 or similar, even if the method does not strictly require the hardfork for consensus. It's just to get an idea what the timeframe was. Or do not include a since: property at all if it is unknown or was available since genesis.

For deprecated:, use the format deprecated: true or leave the property out if it is not deprecated.

For disabled:, use the format disabled: true or leave the property out if it is not disabled.

AC

• [x] For each method, add since: iff it is known which hard fork this method appears.
• [x] For each method, add deprecated: iff the method works but is on its way out.
• [x] For each method, add disabled: iff the method no longer works.
• [x] Any other label types that might be appropriate.

* iff = if and only if

[relativityboy]

@inertia186 Are some of the api operations supported by specific modules or plugins? That information could be very valuable to people setting up their own nodes.

[inertia186]

Only custom_json is plugin specific. Those are documented but could probably still use addition details about the plugins that look for them.