Community discussions

MikroTik App
 
MichaelDC
just joined
Topic Author
Posts: 19
Joined: Mon May 22, 2017 2:40 pm

API differences v6 & v7

Sun Oct 30, 2022 9:35 pm

Hello API Gurus,

I've been using node-routeros on routerOS since v6.4x and up and it worked well for my purpose using streams to continuously display network stats.
Upgrading to RouterOS v7.x, node-routeros no longer seems able to connect to the API and times out (or are the commands failing, I don't know).
Poking around in the connector.js file seems to show the error (TypeError: Cannot read properties of undefined (reading 'bind'))
and also
RosException: Timed out after 10 seconds
at Connector.onTimeout (\node_modules\node-routeros\dist\connector\Connector.js:191:30)

Has anyone had any experience in transitioning from v6 to v7 and what may have changed at API level ?
I tested some instructions (/interface/lte/print) manually using postman and these work, even though some commands seem to have changed,

If anyone has any pointers on where to look it would be most appreciated.

Thanks
Michaël
 
User avatar
BrianHiggins
Forum Veteran
Forum Veteran
Posts: 702
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: API differences v6 & v7

Fri Nov 11, 2022 7:43 am

yup found at least 1 so far under system health. It completely breaks anything that calls that menu because it completely changes the data format on the reply from how v6 responded in an entirely incompatible format. I have an open ticket (SUP-96931) about API changes that brake 3rd party software, but in typical fashion they are being rather obtuse and claiming that changing the API format for one (or more) menu tree functions is totally OK and not in any way changing the API structure once it's published, because it's only a small crash of the 3rd party software they are causing, and "it a necessary change that you will have to deal with a few additional lines in your code.".... it's going to be at least a hundred lines of code f**k you very much.

I'm absolutely furious about the change because it means that I've got to write / test tons of new lines of code tomorrow to deal with their absolute inability to listen to a customer tell them a decision they made was wrong, when I should be packing to leave for my wedding. :-x :-x :-x :-x :-x :-x

and as far as waiting for rolling out v7, I had no choice but to begin supporting a CCR2116-12G-4S+ this week, and it doesn't support v6
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: API differences v6 & v7

Fri Nov 11, 2022 4:27 pm

Before you bought it, it was clear that it didn't support v6,
before you bought it it was clear that v7 could have different APIs,
before you bought it, you have omitted tests on a CHR and have not tried to install v7 on another test device
All before you bought it.

And now they certainly can't put it back like in v6 for your software, which more than "third parties" seems to me only yours...
 
User avatar
BrianHiggins
Forum Veteran
Forum Veteran
Posts: 702
Joined: Mon Jan 16, 2006 6:07 am
Location: Norwalk, CT
Contact:

Re: API differences v6 & v7

Sun Nov 13, 2022 3:50 pm

Before you bought it, it was clear that it didn't support v6,
before you bought it it was clear that v7 could have different APIs,
before you bought it, you have omitted tests on a CHR and have not tried to install v7 on another test device
All before you bought it.

And now they certainly can't put it back like in v6 for your software, which more than "third parties" seems to me only yours...
shove the sanctimonious attitude, it does no good for anyone. You don't know my business and I don't pretend to know yours. Customer's that I have to support had a business requirement that required that model to be deployed. Every other API parameter we tested performed the exact same, except /system/health...

Changing an API data format on a widely deployed platform provided specifically for 3rd party software integration is a horrible practice. It can cause unexpected crashes in other people's software that may or may not be easily or quickly updateable. The reality of your situation is not relevant to the reality of the rest of the population globally. To paraphrase something Normis recently said, the world is quite large, you'd be surprised how much is out there. The fact is changing any part of the API built for 3rd party integration can break 3rd party integration, and because MikroTik does not provide highly detailed documentation outlining changes to the platform that a developer could even know in advance a change was made to a function they call, the only way to find out they made the change is to see your code break after they make a change. Imagine if they decided to just change the WPA handshake or IPSec implementation (which are both a form of an API, as it's built for 3rd party systems to communicate with their equipment for data exchange) because they found a better way and then say it's up to everyone else to update their devices to support the change!

If they want to make an API change maturely and responsibly the correct process is to ensure the default data format remains backwards compatible with existing installations and add the ability to request the data in a different format for developers that want the data formatted differently, or do a total update/rewrite of the API and release it as a v2 with a fully updated library.

Who is online

Users browsing this forum: ko00000000001 and 25 guests