REST API - is it a bug? [SOLVED]

RouterOS Scripting
1

Hello dear - i am trying to write simple ansible playbook, but i stuck.

For example i have one routerboard with ROS 7.12. When i execute call to REST API:

curl -k -u admin:admin -X GET http://192.168.0.1/rest/system/package/update | jq .

{
“channel”: “stable”,
“installed-version”: “7.12”
}

If i log via winbox - /system/packages/check-for-updates and then execute same call to REST API - i see different result:

{
“channel”: “stable”,
“installed-version”: “7.12”,
“latest-version”: “7.14.2”,
“status”: “New version is available”
}

Is it normal behavior? I have checked it on different boards with and CHR with stable ROS 7.9<—>7.14.2 - same problem.

Any ideas and suggetions?

P.S. just checked another board:

{
“channel”: “stable”,
“installed-version”: “7.12”,
“latest-version”: “7.13.4”,
“status”: “New version is available”
}

Why not 7.14.2? I am confused.

2

To check for updates with rest, use POST instead of GET:

USER='admin:admin' ROUTER=192.168.88.1 ; curl -k -u $USER -X POST https://$ROUTER/rest/system/package/update/check-for-updates --json ''

or to actually download & install:

USER='admin:admin' ROUTER=192.168.88.1 ; curl -k -u $USER -X POST https://$ROUTER/rest/system/package/update/install --json ''

Whether its a bug that a GET does NOT match the CLI… IDK. I suspect the CLI returns data it knows at time of the call. Since the new version available stuff requires a fetch, it’s not that odd it should use a POST to cause the remote connection (vs GET which is more to show config).

Perhaps better stated the GET /system/package/update will use a cache’d value form the last check-for-update, if none you’ll get nothing. If last time it check it was 7.13.x, that what it will show since it’s cached. Why you’re seeing variability in the versions. Basically you need to use the “check-for-updates” with POST.

3

Thank you very much - it works.

4

Hey

But what should the post data be? It gives me an error if its left empty but I didn’t figure out the correct post data.

5

I do not think it needs a parameters. But the content-type needs to be set to application/json. So the

--json ''

part does that. If using an older curl, it may not have the --json option. You can try:

-H 'Content-Type: application/json' -d ''

If that’s not it, post the curl command you’re using (with user:password and router IP obfuscated). Also if you’re using Windows…the env vars shown is not going to work — those work in WSL or Linux/Mac.

6

My bad, it was a problem with the group policies. The user didn’t have the correct rights so it gave me the

{
    "detail": "not enough permissions (9)",
    "error": 500,
    "message": "Internal Server Error"
}

But at first I didn’t see the detail as I was using Comfortclick’s http driver to test it and it only said Internal server error… I needed to add policy=local,reboot,read,write,policy,test,api,rest-api policies too, then it worked.

Thank you!

7

HTTP 500 to say not enough permission. It hurts. It is hard to consume APIs that return crap status codes.

Better: HTTP 403 Forbidden

Maybe even another status could be more appropriate.

HTTP 418 for the REST API developer…

8

Your right it’s not a server error so 5xx status code is wrong.

Although the specific permission that’s missing be more helpful.

9

FWIW, if you use Postman to test request, I created a RAML/OpenAPI scheme that allows testing of the REST API. See http://forum.mikrotik.com/t/rest-api-schema-for-postman-more/169502/1

10

I poked it until it worked for me. I gave the API user all group rights and then the command worked - Then I removed the policies one by one. So at the end I left only policy=local,reboot,read,write,policy,test,api,rest-api active. All other commands i’ve added before worked with just group policy=read,write,test,api,rest-api.

I thank you again Amm0 for making the RAML/OpenAPI scheme, it has been useful.