i hope someone can help me with a problem regarding the REST API
The REST API does work with curl, but for some reason a device has problems and i don’t know why.
I’m not even sure who’s fault it is, but i suspect the device, not the router.
Since i have not found a useful log for this (not even debug outputs anything), i did setup a docker container (mendhak/http-https-echo) to compare both requests.
The first request is with curl from a ubuntu VM and the second request is from the mentioned device.
First request disables the firewall rule. Second request does nothing.
I used the same SSL certificate for the debugging container and the router.
Later i generated a new one with 2048 key length instead of 4096 (in case that’s the problem) but that didn’t help either.
The device has default values for the content-type (“content-type”: “text/plain; charset=utf-8”,) which can only be overwritten but not removed.
So by defining “content-type”: “application/json”, it will result in “content-type”: “application/json; charset=utf-8”, which leads to the Error:
{“error”:415,“message”:“Unsupported Media Type”}
You can just leave off a charset. In your example “urf-8” would be in fact “unsupported”, maybe “utf-8” might. But Mikrotik’s curl examples just use a -H “content-type: application/json”, I suspect it’s always UTF-8 without doing anything.
You can also try a tool like https://www.postman.com to test various HTTP/JSON options instead of curl, might be more user friendly for you. From Postman, it has an option for the right curl command line for the operation.
Unfortunately i can’t prevent the device from just adding a charset. I can only change it and add new headers.
You can also try a tool like > https://www.postman.com > to test various HTTP/JSON options instead of curl, might be more user friendly for you. From Postman, it has an option for the right curl command line for the operation.
Yeah it seems the Mikrotik is looking for exactly “application/json” as the “Content-Type:”, just confirm that myself.
I’d recommend filing a bug report at help.mikrotik.com. It really should at least ignore the charset, since I’d imagine a lot of library automatically include “application/json; charset=utf-8” like yours. From stuff like curl, NodeJS or Python, can deal with it. Mikrotik is ignoring the HTTP/1.1 spec here – it needs to accept at least one charset.
This can be reproduced on a Mikrotik with HTTPS enabled using /tool/fetch to localhost even. I call a function to do a /tool/fetch with different Content-Types, which test the problem locally on a Mikrotik.
# you need a Mikrotik user/password to call REST
:global user CHANGE_ME
:global password CHANGE_ME
# "$fetchrest function, it takes a type= in $type to control the Content-Type: used in this test
:global fetchrest do={/tool/fetch url=https://localhost/rest/ip/firewall/layer7-protocol http-header-field="Content-Type: $type" http-method=put http-data="{\"name\": \"rest-put-charset-$[:timestamp]\", \"regexp\": \"test\"}" user=$user password="$password"}
# above rest call adds a layer7-protocol – which are ignored if not used, so safe to add something to them
Which shows the “Content-Type: application/json; charset=XXXX” bug:
Agree the backend logging could be improved. Logging isn’t great in general, beyond just REST, is bigger issue. On the client side, the REST API does return an HTTP error code and short message, and that part seem reasonable. .
My guess converting CLI-syntax into REST is where most troubles lie… since that isn’t always straightforward – but better log may not help much there (e.g. RouterOS doesn’t know why the syntax isn’t working as you expect)
For some issues like certs/content-type/etc or connection issues… Recent V7 release, allow REST over plain HTTP (e.g. not just HTTPS). While not ideal for production, it does allow sniffer to see the traffic & helpful for debugging.
