I have been working with the PHP API scripts for some time now, and I am wondering if there is any chance that the Router->client data might be modernized... The last time I dealt with formats like this was from military ground terminals from the 70's... (maybe I just dont deal with this type of stuff enough to see it used elsewhere?) It would be nice to get the data returned in some current standard though... (and w/o the use of sockets if possible) JSON, <-- extremely light weight, XML (not first choice), or given the nature of the commands:

/system/subssys/command
(and that the OS is already running a lightweight webserver)
REST'ful data retrieval by querying the same command syntax against a secured portion of the web browser..

I'm sure changes like this arent simple, but they would certainly level the playing field and I bet increase the useage (and usefulness) of the API (not to mention reduce the complexity of the API scripts --- they could practically go away)

what's wrong with current format? it's not human-readable? CLI is human-readable =)

and PHP is not the only programming language...

what's wrong with current format? it's not human-readable? CLI is human-readable =)

and PHP is not the only programming language...

1) its archaic and difficult to work with
2) I never complained about PHP -- simply said I was working with it... the other API clients that have been written look very similar to the PHP one (since they all have to do the same work to make the API data usable)

A better API data format such as JSON, XML as mentioned would make for much easier to use, less prone to bugs (due to API client code) tool....

So... My question still stands...

if you have not noticed - sockets are everywhere, just what type, what data is passing through. In linux you open socket to read file, you open socket to read from network, open socket for direct input etc.

API has a lot of features that most of people do not use or use rarely, like proplists - easy way to get what you need, for example. And that is easy way to recognise what is what in api reply.

compared to JSON your line looks like
"ip_address": "1.1.1.1"

in ROS API:
=address=1.1.1.1

if you have used .id or it was just one command you sent, you know that address you are talking about is, and you can see, that =value-identifier= and then comes the actual value field

if you use .id in request you can easily recognise what command returned that data if you run multiple commands and receive results from one socket.

Sadly that made little sense... No comment on the sockets tangent

I know what JSON vs the API data looks like... my argument isnt in appearances, but ease of consumption

$data = json_decode($response); vs reading in and manually parsing a customized word pattern...

Guess I wont expect any actual constructive replies on this at this point.

constructive reply: is there any internal json_decode() in C++, Delphi, etc?..

so, you need any. that's what PHP API Class for

There are JSON handlers in every popular programming language... whether they are native or not depends on the developers of that language...

True, but lacking a native JSON interface on the MT side, you could (once) write an interface between the MT native API and JSON. Then all further tools use that interface.

and these are non-native handlers:

http://wiki.mikrotik.com/wiki/API#Example_client
http://wiki.mikrotik.com/wiki/API#Other_example_clients

True, but lacking a native JSON interface on the MT side, you could (once) write an interface between the MT native API and JSON. Then all further tools use that interface.

This is true, I almost have something like this working for my software, I'm still working out the best format to keep it as simple yet usable as possible... atleast from API->consumption software->API is using a API->write() wrapper that negates the need for the developer to write multiple write() calls everywhere.

and these are non-native handlers:

http://wiki.mikrotik.com/wiki/API#Example_client
http://wiki.mikrotik.com/wiki/API#Other_example_clients

Only because its a non standard format... not exactly the best comparison, especially since being what it is, they are prone to errors due to being exponentially more complex than other possible formats as shown by recent updates to fix API->read() in the PHP API...

"It works decent enough, so I'm happy" isnt exactly the mindset I like to take, so if it can be better I'd much prefer to start a discussion about it, you're attitude clearly shows you arent of the same mind set and you really aren't providing any sound arguments against it, other than 'we have this', 'it works'... So, if that is all you have, then by all means, stop replying and if anyone else has constructive input like Fewi, then lets hear it.

my arguments again:

current method
Pros:
there are existing APIs for some languages
it works
Cons:
API requires complex shifting/splitting of socket data to become usable (more prone to bugs due to complexity)
resembles messaging protocols used in 1970's Satellite terminals, archaic and higher learning curve if you have no preexisting API client

updated method
Pros:
modern message format (be it JSON, XML or other) -- widely used easy to adopt, most languages have preexisting or native parsers
eliminate the need for API client, simply need to know how to send commands and be able to parse the resulting data format (JSON, XML or other) -- some languages may require a 3rd party lib but these are widely available and heavily tested for bugs and standards compliance.
lighter weight
Cons:
requires rewriting some of ROS
depending on how its implemented, breaks backwards API compatibility.

Thats all I can think of at the moment

A side note: Its completely weird and NOT so functional to retrieve the challenge by calling "/login" twice. A "/challenge" to specificly retrieve it also reflects "sanity" tough.

but '/challenge' is four bytes longer

on one side i agree with you - know good parser is very good, but the problem is - API is not targeted for 1 or 2 programming languages that have easy access to some constructs.

API in routeros supports basic TCP socket writing and reading and have some constraints set, that are explained in documentation. That allows for highly personalised applications of use. For example - i can easily run several commands at once and receive responses in a known way, without mixing everything up. Also, some other approach would add a lot of overhead.

Also you already named main reason - a lot of already existing implementations will instantly brake if there will be changes, but IMO that is main reason why API is there - so there is know command interface to connect to and execute commands, so changes that radical will not happen.