Hi there,

Friend of mine runs a cafe. I'm trying to improve the situation here since the Asus is unstable. So I trying to sell the Mikrotik.

The one problem I am hoping the Mikrotik can solve, is to provide a Restful API to query number of active DHCP leases. I.e. show number of users in the cafe at any one time.

Can that be done?

Many thanks,

Don't know iif any of them provides REST functionality, there's plenty of API implementations in several languages, have you checked (at the end of the page) http://wiki.mikrotik.com/wiki/Manual:API

There's also a new perl module, see http://search.cpan.org/~martingo/MikroTik-API/

Thanks. I created the API & made a video about it:
https://www.youtube.com/watch?v=HaMNA5pUHiE

Well, now I feel stupid for not pointing out my API client (which I usually don't do when "PHP" is not mentioned).

With it, the equivalent of your PHP script would be: and so I must ask what made you choose the Denis Basta client?

and so I must ask what made you choose the Denis Basta client?

Usually PEAR PHP packages scare me. And yours seems sadly no different.

12980 SLOC versus 540 SLOC. I choose less code. http://ix.io/mVS

and so I must ask what made you choose the Denis Basta client?

Usually PEAR PHP packages scare me. And yours seems sadly no different.

12980 SLOC versus 540 SLOC. I choose less code. http://ix.io/mVS

Finally! A somewhat reasonable response to that question...

And my reaction to it... Given the feature set, it's inevitable that my API client would be far larger. If you want to make a fairer comparison (one where the features per SLOC are more or less equal), you should compare the lines of "/routeros_api.class.php" vs. the lines in "/src/PEAR2/Net/RouterOS/Communicator.php", and count the "Code" lines.
(Everything else is optional extras that make things easier than "word-for-word" communication; And doc comments are helpful to IDEs, and in turn, to you - that's why they're ~30% of the total lines...)

Sure, even in that reduced set, you'll probably see more statements, but I don't think Denis Basta's client allows you to send seekable streams, on-the-fly convert between charsets, or do persistent connections.

Admittedly, the charset conversion is probably better handled on higher layers, and persistent connections aren't a "must have", but still - seekable streams. Those allow you to send and receive large amounts of data without consuming too much of the web server's RAM. You can't really do that with Denis Basta's client - you have to get the whole data as a string, at which point you consume that much additional RAM.


Side note, I've previously gotten more "factual" statements that are either false, or true, but plain silly...
"It doesn't support PHP 5.2" - Yes, but... Really? Does anyone NEED to support a version THAT old?
"It requires PEAR(2)" - No it doesn't. It's named that way merely because it sits in the PEAR2 repository.
"It's not easy to install" - What's easier than including a PHAR file?
"It's a beta" - It's FAR more stable than the Denis Basta client, in terms of error prone-ness. The "beta" refers to the possible changes in future versions (i.e. "beta" = "existing code may break when upgrading"), not to error prone-ness of the current one.

"It scares me because it's big" is a nice new line of reasoning, even though it's a more subjective one.

"It scares me because it's big" is a nice new line of reasoning, even though it's a more subjective one.

Is it a really a new line of reasoning to choose less code?

I also despise OO code. I must be unique!


Not sure why Mikrotik have made charset conversion an issue. I assume they don't use something sane like UTF8?

In an ideal world I wish I could just fetch some JSON from 192.168.88.1.

Sadly their JSProxy thing is some binary format & not JSON.
http://s.natalian.org/2015-12-23/145083 ... 8x1058.png
Also annoying that "ip dhcp-server lease print" inconsistently maps to /webfig/#IP:DHCP_Server.Leases. Poor design.

Else I guess I could have just used something like "ssh admin@192.168.88.1 ip dhcp-server lease print".

So I am not defending BenMenking's Mikrotik library. Especially with stuff like: https://github.com/BenMenking/routeros-api/issues/13 ... it doesn't seem maintained.

"It scares me because it's big" is a nice new line of reasoning, even though it's a more subjective one.

Is it a really a new line of reasoning to choose less code?

It's a new reason to me in terms of choosing one API client over another.

(In general terms, no, it's not new... It's common for small libraries to gain more traction - one way I've heard it being called is "the puppy syndrome" - users choose a small library, and start wanting more out of it; I've merely skipped the puppy phase, because I think I'm able to handle the monster )

I also despise OO code. I must be unique!

Maybe not unique, but you're certainly "rare". Most people either love it, or don't care either way. Despising it is rare.

Not sure why Mikrotik have made charset conversion an issue. I assume they don't use something sane like UTF8?

In fairness, it's a Winbox issue, not so much a RouterOS issue. Winbox uses the windows ANSI charset, while the API gets the raw data, and RouterOS has no problem storing data in any charset.

So yeah, MikroTik could fix it, except that doing so will mean they also have to introduce handling for invalid UTF-8 characters in Winbox - handling that would inevitably make any non-latin users furious that their carefully crafted names and comments are now shown as "???".

In an ideal world I wish I could just fetch some JSON from 192.168.88.1.

And push some JSON to 192.168.88.1 when you want to write? "In an ideal world", sure.

Poor design.

I'm sad to say the same can be said about most aspects of RouterOS scripting and API. I've been pointing out just some of the most annoying ones to support, and the response has generally been "Thanks, we'll fix it... eventually... maybe...", and in rarer cases, it's been "We won't do it in this way, or otherwise address this scenario, because [insert nonsensical reasoning]".

So I am not defending BenMenking's Mikrotik library. Especially with stuff like: https://github.com/BenMenking/routeros-api/issues/13 ... it doesn't seem maintained.

So you're just saying you think of it as the lesser of two evils. Got it .

Thank you for sharing that.

I'm starting to think other times when I haven't gotten ANY answer to that question has been more or less THIS, but people thought they'd be insulting me or something if they tell me... But no, I feel relief for knowing, not anger or sadness. I can now start to think about how I can make things better. I can't really reduce my API client's size without sacrificing useful features, but if I can make it feel less scary, that would be equally good I think.

Thanks for taking my "critique" or rather comments on the chin!

And push some JSON to 192.168.88.1 when you want to write? "In an ideal world", sure.

To interact with the ideal Web API (which doesn't exist in the Mikrotik world. WTH is jsproxy anyway?!), a standard GET or POST parameters would be fine. I certainly don't expect to write with JSON to trigger an action.

However it would be nice if the config could be in JSON instead of that mysterious supout.rif. And I could make changes or edit to it and then write that as the config.