I'm trying to add an ability to my API client that tries to emulate numbers by creating and maintaining an index of "number to ID" mappings.

I've read that IDs don't change within a single session even after CRUD operations, which I guess is good news for performance, but... how is the initial number list generated?

I thought that the IDs are sorted (in ascending order) and that's the starting point... but apparently, not so - not only do my PHP tests produce misleading results with that assumption, but on closer inspection, the IDs aren't even sorted in terminal (e.g. my first two simple queues have IDs "*4d5" and "*4d6", while a queue MUCH later on in the list has an ID "*102"; all that after logging out and in from Winbox, so IDs are sure to be fresh).

So how does the number list get generated at all if not by ID sorting? Whatever order "print" responses arrive in? I thought those are supposed to not be significant... right? Or is that only in the API protocol, while there's significance in terminal?


Note: I think I might have a workaround involving creating a script that processes this, and then finally retrieve the results, but this is very performance costly (not to mention that it means users will be required to have writing privileges, even if they're just reading), and so I ask in hopes to avoid it.

EDIT: Actually, rereading the API spec now, it's the order of properties that shouldn't be relied upon. Should I take this to mean that I can rely on the order of "print" reply sentences to match the numbers? This certainly appears to work on my RouterOS version (5.6), but the question is if that's intended, or just a coincidence.

IDs are generated for interactive console sessions. You can't depend on them outside of that.

Use the "find" command in your script instead, that works reliably. A useful tip in certain cases is to put unique info in the comment field and then search based on that.

http://wiki.mikrotik.com/wiki/Manual:Scripting

This is about the API, not about scripting.

With the API, "find" works fine for giving you all IDs and nothing more. There doesn't seem to be a way of feeding "find" a number, and getting the ID out of that - not with a query, not with a "numbers" argument or anything of the sort.

BTW, although your reply doesn't answer my question, still - thanks for making me check out "find". It will serve good for most efficiently refreshing the "number to ID" index I was talking about, since it delivers all IDs within a single reply, as opposed to "print .proplist=.id" which delivers them across multiple responses.

The question can now be paraphrased - Does the order of IDs returned by 'find' reflect the numbers a terminal would use? Again, this seems to be the case currently, but is it "given" that these would match up?

I generally find it easier to just upload scripts and execute them. Mikrotik is forever making minor changes that break scripts but the API seems to be worse. With scripts at least I only have to relearning one notation when something changes.

API syntax has not changed since the introduction. If CLI structure changes, of course API will change to reflect these changes.

New features only expand API to add new things that are now possible, like queries, what you do not have to learn if you do not want to use them.

@tjc Well, in my API client's latest version, I also have this for people that feel similarly to you, and yet need to interface with PHP non the less.

@janisk Any chance I could get my question answered too?

Does the order of IDs returned by 'find' reflect the numbers a terminal would use?

it is not guaranteed to be the same order number given by CLI print command. Better use different indicators, like contents of the comment field to identify the same thing in API and CLI for human operators.

There is also a problem, that CLI numbers are given only after print is performed on the list.

My choice usually is to use .id ID numbers to access rules.

Also, from your first post - .id fields are constant for rules that are added statically through out life of the item. But the order they are given out is not set and can vary from the item list to item list, sometimes numbering may be reset sometimes not.

it is not guaranteed to be the same order number given by CLI print command

OK. So if I'm getting this right,
("API find" = "CLI find") != "CLI print"
(in terms of order of IDs)

But the order they are given out is not set and can vary from the item list to item list, sometimes numbering may be reset sometimes not.

I get that, but within an item list, when doing a "print" on it, can the order of the items given by that "print" (for that particular item list) always be considered to reflect that of CLI?

That is, for example, can the order of replies by, let's say "/queue/simple/print" reflect the order produced by "/queue simple print" in CLI (assuming no add/move/remove happens in between)?

Or to put this in another way, is
"API print" = "CLI print"
(in terms of order of replies)


What would be a more reliable way to get replies in an orderly way if not this?

My choice usually is to use .id ID numbers to access rules.

Sure, but I'm doing this for the sake of people who are sure they're targeting the right entry, and are willing to shoot themselves in the foot otherwise.

there is no promise that item order will be as it is between print commands in either API or CLI. There are some object lists that promise that - like '/ip firewall' where you can move items around and print will give you a correct order of objects. Everywhere else it is not possible to make any assumption.

so, using your formula

Case A - "CLI print" != "CLI print later" != "API print"

This is due to logic that CLI is not the entity that orders/manages items.

doing "/ip firewall filter", "/ip firewall mangle", "/ip firewall nat" prints will yield the same order every time. so
case B - "CLI print" === "CLI print later" === "API print"

I see. Thanks.

Well, in this case, I have a feature request.

Add in API some way of getting commands and/or menus and/or arguments available from a context, similarly to the "?" from terminal. Perhaps even make it "?".

Example protocol flow (the !trap contains "help=yes" to make it clear that this version supports the "/?" command, but it fails for this particular item non the less; it doesn't need to be this particular indicator, just as long as it's different from the current kind of error for non-existing commands, and not just in terms of the message)

Or maybe make it an API specific command called let's say "/help" that would receive the context as an argument, e.g. Either way...

This would allow me to detect if there's a "move" command in the current menu, and act accordingly, and it would also even allow for some other fancy stuff... like perhaps maybe I could pre-validate commands or better yet - pre-generate objects (ORM, here we go!).