I know I put this up before. (Please add a +1)

Guys, would it benefit you? Please think about it.

Guys can we encourage Microtik to add REST API for Microtik.

Nearly all the API's we use now days are REST.

To use REST is 5 minutes, to use the Microtik API, well it's not 5 minutes

REST, JSON and XML

It would make management of Microtik devices a dream.

We would use it to change routing, add firewall rules, add to address lists to block spammers, port scanners and everything else, amend BGP etc

Can you Guys Please add a +1

Thanks

Tony

+1 from me

what does REST API offer the the current doesn't?

The current API takes 3~5 minutes to setup and is very simple to use.

what does REST API offer the the current doesn't?

It's stateless. And usually done using simple HTTP methods (GET,POST,PUT,DELETE).
You can do things (if the API is designed that way) even using simple curl commands instead of writing wrappers or using 3rd party libs to be able to talk to it in a sane way.
Especially helpful during development.

https://en.wikipedia.org/wiki/Represent ... e_transfer

The current API is a kind of a mess IMHO.
Every time I tried to use it for a project I ended up using SSH to issue commands instead.
Not to mention the fact that not everything is implemented in the current API (so again, SSH was the only way to go).

So +1 from me as well

what does REST API offer the the current doesn't?

The current API takes 3~5 minutes to setup and is very simple to use.

I disagree, that it takes 5 minutes to use, it depends on what language you are using? and with an API it shouldn't

How much can you do in the existing API that you can do in Winbox, 100%? I don't know but it will be interesting to know.

Microtik please can you answer how much you can do as an approx % in the API compared to Winbox?

1) Everyone could use it not just a minority, in almost any programming language with no effort
2) Microtik would get more customers with a good REST HTTP API
3) An easy to use API is pretty much a sales benefit nowadays, Microtik would benefit
4) I would buy more CR1072's and other kit
5) 1 example using curl, no other examples required.
6) XML and JSON are more structured, Easier for Microtik to expand its features. No Wrappers.
7) Developers using good API's are what makes tech companies large. (aka AWS), AWS would not be big without easy to use API's

An API should be easy to use (irrespective of programming language) REST HTTP is language agnostic.

I can connect to Salesforce, XEN, AZURE, Google Cloud, Dropbox, Twitter, Microsoft Cognitive services, Cisco, IBM, OpenFlow, Slack, Docker, Kubernetes, AWS, most if not all SDN switches, in fact, I would be surprised if any provider with a new API did not provide a REST interface.

With REST and HTTP I could use it on Windows, Linux, IOS, Android, Windows Phone, MacOS and Webdev within 5 minutes if I so wished.

I don't see, Microsoft, IBM, Google or anyone providing an API with this kind of help files. So Microtik either wants to use an API for a few programmers or provide an API that makes it easy for customers that will actually get them more customers.

https://wiki.mikrotik.com/index.php?tit ... I#Protocol

0 <= len <= 0x7F 1 len, lowest byte
0x80 <= len <= 0x3FFF 2 len | 0x8000, two lower bytes
0x4000 <= len <= 0x1FFFFF 3 len | 0xC00000, three lower bytes
0x200000 <= len <= 0xFFFFFFF 4 len | 0xE0000000
len >= 0x10000000 5 0xF0 and len as four bytes

With REST and HTTP you need one example. You do not need any examples of programming languages, 1 example using curl is sufficient.

Microtik could also put up a Developer REST API Simulator like other providers do.

i was just asking for "/whatever print json" (or /whatever print xml [for the serious old school folks) functionality in addition to "xxx print terse" or "xxx print detail" a while ago.
doesn't seem to be a big deal for me at all.

to be honest sending commands over ssh does work just fine, and i have nice results.
whenever i wanna do things in batch fashion, just upload a file with a set of commands via sftp, then do an "/import verbose filename.rsc" over ssh, and boom there it is.
but since 6.41 the auto_xxx feature from ftp was integrated into sftp, it is less effort to accomplish.

all i miss from the CLI is the structured data output (print json) - which is present in API in mikrotik's own format that has context and session awareness, so in a far superior way i can pull it off by launching short lived ssh sessions with autocommands.

one must admit, that in many points in routeros you may only do changes if you have the correct reference id for that specific session - at places where the objects do not have name attributes to refer to. so whatever you do there, it must come down to the "identifiers displayed in the previous print output of the same instance of the respective menu level". i do not know any "easy" way to transfer this behaviour to REST w/o crucial changes to the infrastructure. and those changes may be to expose certain internal UUIDs to refer to in terms of "set" or "remove" actions.

my "workaround" for this situation was to use the "comment" field to store UUIDs generated on orchestration side for each object, but there are still some contexts where there is no comment capability in routeros. then manipulation of those "tagged" objects was easy as 1-2-3: all in all, since API has SSL transport for a while, the only downside is that it uses some exotic port numbers, whereas ssh runs over tcp/22 so i have both automation and on-demand cli access done over a single channel. i must however admit that no one scans for "open routeros API ports", but tcp/22 is kind of crowded all the time

so if mikrotik will have an API exposed over HTTPS with REST, and this will be - say - switchable whether it's just the API or Webfig or both, count me in.
all in all i don't really think that it would be that hard to create a REST->API bridge in a modern programming language (RoR, perl catalyst/dancer, flask via python)... in fact i will just give it a try as i have some free time.

i was just asking for "/whatever print json" (or /whatever print xml [for the serious old school folks) functionality in addition to "xxx print terse" or "xxx print detail" a while ago.
doesn't seem to be a big deal for me at all.

to be honest sending commands over ssh does work just fine, and i have nice results.
whenever i wanna do things in batch fashion, just upload a file with a set of commands via sftp, then do an "/import verbose filename.rsc" over ssh, and boom there it is.
but since 6.41 the auto_xxx feature from ftp was integrated into sftp, it is less effort to accomplish.

all i miss from the CLI is the structured data output (print json) - which is present in API in mikrotik's own format that has context and session awareness, so in a far superior way i can pull it off by launching short lived ssh sessions with autocommands.

one must admit, that in many points in routeros you may only do changes if you have the correct reference id for that specific session - at places where the objects do not have name attributes to refer to. so whatever you do there, it must come down to the "identifiers displayed in the previous print output of the same instance of the respective menu level". i do not know any "easy" way to transfer this behaviour to REST w/o crucial changes to the infrastructure. and those changes may be to expose certain internal UUIDs to refer to in terms of "set" or "remove" actions.

my "workaround" for this situation was to use the "comment" field to store UUIDs generated on orchestration side for each object, but there are still some contexts where there is no comment capability in routeros. then manipulation of those "tagged" objects was easy as 1-2-3:

Code: Select all

set [find comment="1886bb13-b882-43bb-a0e1-5a40f50aa8b2] whatever=whatever-else

all in all, since API has SSL transport for a while, the only downside is that it uses some exotic port numbers, whereas ssh runs over tcp/22 so i have both automation and on-demand cli access done over a single channel. i must however admit that no one scans for "open routeros API ports", but tcp/22 is kind of crowded all the time

so if mikrotik will have an API exposed over HTTPS with REST, and this will be - say - switchable whether it's just the API or Webfig or both, count me in.
all in all i don't really think that it would be that hard to create a REST->API bridge in a modern programming language (RoR, perl catalyst/dancer, flask via python)... in fact i will just give it a try as i have some free time.

Hi,

Thank you, I will try over ssh, if that works like you say I will use that and it will solve my problem.

It's interesting you're using ssh and not the API. I may be wrong on REST but it would be an interesting discussion, if we as users don't discuss features like the API, Microtik will never know who can use it easily and who can not.

You could have REST and streaming like twitter, depending on what you are trying to achieve but I like structure like XML and JSON so REST seemed a good idea.
https://dev.twitter.com/streaming/overview

So it would be good, if others can comment constructively that would be great, If I am wrong I am happy to say so, no big deal I just find the API difficult.

Thank you

Tony

TL;DR REST or any other thing changed will not change the limitations that are brought by RouterOS.

Limitations in current RouterOS API are not something artificial or on purpose - those are technical limitations on what can be done at all. Commands that require user sessions like telnet, mac-telnet and ssh are not available as there is no way how to make those commands work without the console. A similar story is for scripting - but it is possible to make sa script and execute it via API, but not inline as that can be done in the console.

Some scripting languages like LUA are very easy to use with the RouterOS API as the RouterOS reply can be easily loaded in LUA table and then easily manipulated from there. One of the simplest uses would be to output JSON.

How much can you do in the existing API that you can do in Winbox, 100%?

I would say 99%

Commands that require user sessions like telnet, mac-telnet and ssh are not available as there is no way how to make those commands work without the console.

to be totally honest, there are some unnecessarily "interactive" commands, that could use some improvement. for example "dangerous" ones that require user confirmation "[y/N]", could have a non-interactive option, like confirm=yes to skip the pop-up.
there are some already addresses things, like "monitor xxx once" which gives access to data you cannot really get otherwise but it does not require the user to interact (press Q or CTRL+C to stop), or "duration=xxx" for sniffer or wireless scanner.

but there are also some points, where a "duration=xxx" can be of help [sorry, can't name nothing right now, but i will], and in case of "monitor", like in "/interface ethernet monitor sfp1" a structured access to values shown there would be really great (i.e. transceiver rx/tx power level, etc).
and there are some "monitor" commands where the "once" argument just doesn't work well, like getting cell info from 3G/4G interfaces, as it requires 2-3seconds to respond, but "monitor once" returns instantly with no data.

+1 for rest

I think you'd probably find a lot more developers taking interest in producing apps and integrations for Miktorik products if implemented

@NodeMax
I think the complexity with the API you're perceiving is due to the fact that the manual page is not intended for users of the API protocol... It's intended for implementers of the API protocol. I mean, if implementation details are how you're judging ease of protocols, then the HTTP protocol that REST APIs use is actually far more complicated than the relatively simplistic RouterOS API protocol.

But either way, the comparison is still unfair, due to the stateless vs. stateful distinction... A more fair comparison is to DB protocols, which are stateful. Be it MySQL, MSSQL, PostgreSQL, etc. - all DB servers have their custom protocols that each programming language needs to implement to interact with them, resulting in many DB "examples". Despite that, you're probably not going to call them "examples", you're calling them "DB clients", and "examples" is what you call the SQL queries, some of which can actually be used across different DB servers.


All of that said, I think there is something MikroTik can do to fix the perception of the API, and that is to rework the language and organization of the manual... The current Manual:API page should instead be renamed to "API Protocol Specification", the section "Examples" should be changed to "Example API Protocol Clients", the "API command notes" page should be merged with the actual specification (as many of those notes are important for implementers of higher level wrappers), and there should be a separate page intended for API users (let's say called "Manual:API", replacing the current page), where protocol limitations and CLI differences are discussed with example "protocol flow" visuals (like the ones currently in the "Command examples" section of Manual:API, but more of them, for each difference from CLI), and there's perhaps code examples with API clients from two or three different languages, to allow users to try out the example protocol flow visualizations out.

All of that said, I think there is something MikroTik can do to fix the perception of the API, and that is to rework the language and organization of the manual... The current Manual:API page should instead be renamed to "API Protocol Specification", the section "Examples" should be changed to "Example API Protocol Clients", the "API command notes" page should be merged with the actual specification (as many of those notes are important for implementers of higher level wrappers), and there should be a separate page intended for API users (let's say called "Manual:API", replacing the current page), where protocol limitations and CLI differences are discussed with example "protocol flow" visuals (like the ones currently in the "Command examples" section of Manual:API, but more of them, for each difference from CLI), and there's perhaps code examples with API clients from two or three different languages, to allow users to try out the example protocol flow visualizations out.

+1 for this bit. This can be done now, no need to wait for RouterOS 7

only offical code is the API client for Python 2. I can expand on how to use that particular client. And list limitations for API commands as such. All the rest, as described by boen_robot, indeed applies to implementers of the actual code. In this case - the REST API would be just a library/an interpreter that would allow input commands in that particular form/variation.


Now - the user interaction part
Also, there are commands, that seem to be interactive, but they are not, like, "/system/reboot" does not need any confirmation. Interactive commands are underlying RouterOS tools, where console interacts with them and they cannot perform properly because a certain interface is required by the tool, that cannot be provided by the API. Such CLI commands are - "/system telnet", "/system ssh". Some other tools have been reworked ground up to be able to interact with the API.

There are many such "interfaces" hiding under monitor command in CLI, if you need some particular that is important for you, ask for it.

As such - REST interface would not resolve any of the issues we have currently for programmers implementing API vs the users using ready made tools based on API.

Also, you as users have the privilege to see actual API you can work with without burden of using language that we here chose to work in. You can use whatever you want, that fits your deployment requirements/developer knowledge.

+1 for REST API in RouterOS, I really would love to see REST API in Mikrotik !

+1 for the REST API.
I use Mikrotik to connect smartphones to wi-fi network for testing applications. There are lots of Jenkins provided tests being fired up on these devices all the time. Having REST API would be perfect for creating automatically triggered Jenkins tests responsible for decreasing bandwidth or even turning off wi-fi signal.
If someone knows how to do such things using existing API, please enlight me.

REST API ruleZ!!!

It will be very nice if you can do the REST API. The development will be much faster since this is a standard way for API development.

+1 for REST based API!!