All “APIs” in RouterOS really go down some fixed schema. And the CLI has a tool /console/inspect that allow you kinda see the scheme, which AFAIK guides what REST accepts. FWIW, if you want do a lot with REST API, I publish the “schema” that’s usable in tools like Postman here: https://tikoci.github.io/restraml with a discussion of how to use it with Postman and VSCode here: http://forum.mikrotik.com/t/rest-api-schema-for-postman-more/169502/1
So /console/inspect does tell you want numbers is defined to & for script/run it seems to include names. If you want to get into the weeds, you can kinda see what might be going on – still kinda odd REST takes name as .id however:
> /console/inspect request=syntax path=system,script,run
Columns: TYPE, SYMBOL, SYMBOL-TYPE, NESTED, NONORM, TEXT
TYPE SYMBOL SYMBOL-TYPE NESTED NONORM TEXT
syntax collection 0 yes
syntax explanation 1 no Item number
syntax use-script-permissions explanation 1 no
> /console/inspect request=syntax path=system,script,run,number
Columns: TYPE, SYMBOL, SYMBOL-TYPE, NESTED, NONORM, TEXT
TYPE SYMBOL SYMBOL-TYPE NESTED NONORM TEXT
syntax ItemName definition 0 no
syntax definition 1 no _YAML | rancher | > lsbridge > | > PIANO > | …
So looks to be .id or name,… So maybe REST API must map .id to the generic if there is not an “.id”?
But leave it @jaclaz to actually try using .id with a name. Since REST API does just map into the native API, and from API it also takes a name from /system/script in a quick test. From a pure API design POV, it really should fail if you explicitly use .id IMO.
The net is “number” will take a name, which might be better than .id… — which is strange sounding, but “number” is in the schema it seems. In RouterOS [7.16+] fetch syntax (to itself), that works:
/tool/fetch user=$routerlogin password=$routerpasswd http-method=post url="http://localhost/rest/system/script/run" http-header="Content-Type: application/json" http-data=[:serialize to=json {"number"="$myscriptname"}] output=user-with-headers