I've written a proposal for a new API specific "/help" command in the wiki:
http://wiki.mikrotik.com/wiki/Proposal_API_help

I'd like to get some feedback from MikroTik, as well as other authors of API clients, API users and editor creators, since this will affect them too.


And before anything else... Yes... I know this is a big addition. Even if immediately approved by MikroTik staff "as is" with an enthusiastic "We'll do it as soon as possible!", I don't expect to see it in the next few RouterOS releases.

regarding hash - you can already check built-time of the package that will correctly reflect on same or other version of packages (even for incorrectly named endless rc1 builds that are about to stop). So, creation of hash can be left for client end as all you have to do is append build-time to hash function number of enabled packages.

Indeed, but this requires the client to assume the existence, exact location, format, and semantics of the package print command. In other words, it must assume the existence of the "/system" menu, the existence of the "package" submenu, the existence of the "print" command, and the existence of the "detail" argument, their semantics, as well as assume that the names and times can be found in the "name" and "built-time" properties.

I mean, what if, in v7 for example, you rename "build-time" to "time-built", "build", "compiled-at", "compilation-time", "creation-time" or something similar? Or if the package list is moved from "/system package" to just "/packages" or whatever?

Or (a more likely scenario), if perhaps you allow 3rd party extensions, which you decide will be using a dedicated menu (e.g. "/system extensions", or "/packages mikrotik" + "/packages others"). Those will also have to affect the hash, yet API clients wouldn't immediately know about them.

The whole idea of the "/help" command is to prevent such (and other) assumptions, until reported, replacing them with only assumptions about the "/help" command itself. In the case of the hash, a client only needs to assume that (if there's no !trap reply...), there will be some sort of unique identifier at the "ret" attribute, which identifies the whole set of menus, commands and arguments.

If you're worried about the performance of RouterOS - the hash only needs to be generated once at install/upgrade/downgrade time, or once upon a package (de)activation, after which it can be stored. These things happen fairly rarely, and besides, MD5 or SHA1 are quick to compute. So the impact on the router's performance is therefore non-existent, except at those key (but again - rare) moments, at which point there's a minimal, if not negligible, impact on the CPU. If the hash is stored in RAM for the purpose of quick access, there's only a minimum RAM impact - a few bytes for the hash (16 bytes at minimum for binary MD5, 40 bytes at most for character SHA1).

i understand you completely and feature request of this functionality is there since API creation. Unfortunately it is of low priority and as i was told, probably we will see LUA before this.

i understand you completely and feature request of this functionality is there since API creation. Unfortunately it is of low priority and as i was told, probably we will see LUA before this.

Daaaaamn. Knowing how much of a low priority LUA is... that's some REEEEEALLY low priority stuff then.


I understand I'm asking a lot particularly in the area of argument values... But is there any possibility for at least the menu/command list (section 2.2) to be squeezed in? Not as a "high" low priority necessarily... but just "higher than LUA" high.

I really wish MikroTik would consider raising the priority on this. Here is my slightly philosophical view on the matter.

We are in a world of software services running everything, with automation and integration becoming the norm. APIs are no longer afterthoughts, but are designed into the core of products and form part of product strategy.

Winbox is great, but it's a tool that's used to setup or troubleshoot, as is the web interface and the command line. Scripting has it's place. The API is different in that it allows us to extend the RouterOS platform do things which we can't using just Winbox or scripting, or to do them easier. Specifically, it allows us to do things which are:
* Centralised
* Autonomous
* More reliable
* Parallel
* More intelligent

Products that allow integration and extension will have a competitive edge on those that do not.

Allowing the user to discover available functionality using the API will allow developers to create applications that can do things that will rival both the existing tools and the competing platforms. Any feature that improves the API should, in my opinion, be near the top of the list, and not the bottom.

Any news on this? I think boen_robot's proposal is great! My usecase for this feature is auto-generation of Go (golang) client library. It could be run for each new version and it would generate the appropriate structs and methods for that version.