How to get the correct value for the numbers parameter ? Should I first enumerate all interfaces ? What for, if I know the name? Bit useless roundtrip and parsing on client side
If using =interface= parameter is wrong, why API doesn’t return “!trap” ? It just gives me “!done”
And why in other areas (as I mentioned for example on setting SSID) the =.id= parameter is accepted with interface name.
I thing API is bit buggy and inconsistent in many areas. The same syntax from CLI perspective requires different approach from API coding.
I have an emails from Mikrotik guys from Jan 2014 that they are warking on concepts around API, what should be done next and how… nothing changed from that time.
But back to bussines… What about my 1) question ?
EDIT
Just verified… it works only with " =.id= " parameter as selector of interface on which I want to change IP. To get it I need to /ip/address/print, then parse whole output to find the .id of interface I want to play with.
EDIT
And what is strange and confusing this works perfectly
as you can see there is no id (like *3 od something what can be found in print output) in =.id= value. There is just plain interface name. And API accepts this and SSID is changed.
If you know the name, you can use the name as a value for the “numbers” argument. However, in the case of the “/ip address” menu, there are no names to begin with, unlike, say, the “/interface” or “/queue simple” menus.
If you don’t know the name (or there aren’t names, as in here), you need to then use “print”, along with a query that would match the desired item(s), and get their names or IDs from the output.
If using =interface= parameter is wrong, why API doesn’t return “!trap” ? It just gives me “!done”
“interface” is a valid property you can change on a matching item. For example, you can specify that a particular address that was previously assigned to ether1 would now belong to ether2 instead.
It’s just that without “numbers”, there are zero items matched, and thus a set is “successfully” executed on 0 items. IMHO, yes, there should be an error for a missing required argument (that one being “numbers”), but regardless, “interface” is a valid argument name.
And why in other areas (as I mentioned for example on setting SSID) the =.id= parameter is accepted with interface name.
It seems to me the “.id” argument was never intended to be used as a way to target items… Or perhaps it was at one point, but MikroTik have come to realize this is not consistent with how CLI works, and are trying to fix it. CLI uses normal arguments (usually “numbers”) to target items, and so that is how the API is modified to be like.
Like I said, the “/ip address” menu does not have names.
In menus like “/queue simple”, the name of a queue is a unique identifier for an item, hence you can use it to target a queue, and similarly with the “/interface” menu to target an interface, “/ip hotspot user” to target a user, etc.
Items in “/ip address”, “/ip arp”, and a lot of other menus are NOT uniquely identified by a name. You can have several IP addresses for an interface, so you can’t use the interface name as an identifier IN THOSE MENUS.
You’ve already found the only allowed way to target items in the “/ip address” menu - “print”, and then take the “.id” of the item that you want to edit. To filter out all IDs for only the one(s) you need, use queries, e.g.
Well, there is, if you wanted to modify ALL items together (like, let’s say you wanted to set them all with the same comment) - you could use “find” to get all IDs in the current menu, all in a single property in the response called “ret”.
To increase the efficiency of print requests, you can also use the “.proplist” argument to list (in a comma separated list that is) only the properties you want, in this case just ID, so:
You still get a sentence from which you need to extract the ID, but at least that sentence won’t be “polluted” with the current addresses and interfaces.
Sadly, there’s no more efficient way currently. It has been proposed (and I concur) that commands other than print should accept queries themselves, as means to target items, so that you could f.e. do
to change all IP addresses of “hotspot_bridge” to be assigned to “ether1” instead.
This is not (yet) implemented in RouterOS however, and MikroTik have not announced any plans to eventually support it (though they haven’t explicitly said “No way!” either, so THAT is promising…).
It’s there 
