Vote for Zabbix API

[Alexei]

We would appreciate if everyone interested in Zabbix API would vote for his favorite implementation of the API very much.

Please include brief arguments defending your choice.

[nelsonab]

I'm assuming you will follow the JSON-RPC standard?
http://http://en.wikipedia.org/wiki/JSON-RPC

http://www.apps.ietf.org/rfc/rfc4627.html

Are you looking to do JSON-RPC over TCP or HTTP? Using HTTP as your transport protocol can make some things easier, over TCP things might be quicker and in some cases easier to work with given a good client library.

I also wonder about the client libraries. I did a quick search for a Ruby JSON-RPC library and didn't come up with very many. I also wonder about the maturity of the code for some of these libraries, but this is just pure speculation at this point.

I think REST would be a good interface to allow for "pulling" data from the Zabbix server. Perhaps someone could write a REST wrapper to JSON-RPC.

SOAP is pretty cool, but setup and implementation can be a pain, but once that pain is done it's pretty cool.

Straight XML-RPC, no thank you!

[Alexei]

Yes, I mean standard JSON-RPC. We are thinking of JSON-RPC (or other protocols) over HTTP, so the code will be on the front-end side, i.e. implemented in PHP.

[nelsonab]

Ok, if I understand you right you're saying that you'll implement the API from within the Web Frontend. Makes sense, easier to impliment there.

[Tom]

Hi all,
Voted for JSON-RPC. Reasons?

• Good Bi-directionality
• Low overhead
• Well supported by the major programming languages I work with

Tom.

[Aly]

Just my 0.02$ :

I would pick up SOAPjr: http://soapjr.org/
This is simplified SOAP protocol and realized through JSON.

Why:
1. JSON-rpc is too simplified, I would prefer more strict way doing things.
2. XML - is too heavy and not so comfortable to work with.

[nmail_uk]

I can see JSON has got the lead so far, however I've voted for XML-RPC. My reasons?

Mainly because my desired use case will be using a C++ application to fetch details of client's system out of our existing management system and add them to ZABBIX to be monitored. All the interfaces our system currently supports (for billing and provisioning etc) are XML handled by a single server-side application, and I'd prefer not to have to code two different sets of interfaces.

XML can be read pretty easily in PHP, and we've developed an in-house LINQ-style (.NET programmers will know what this is) handler in PHP for reading and writing XML.

SOAP is, in my opinion, a bloated construct based on XML anyway.

[Farzad FARID]

I'd favour REST over SOAP (even simplified)

Hi,

Compared to REST, which is my favourite, I think "simplified SOAP" is too exotic. Besides, apparently no project uses it.

Many open source or "agile" applications now use REST as their API. For me Zabbix falls into this category.

Some examples of projets using REST:

• OpenSSO
• Facebook only provides REST http://wiki.developers.facebook.com/index.php/API
• Digg is also REST-only http://apidoc.digg.com/
• Chef (the next generation Cfengine / Puppet) http://wiki.opscode.com/display/chef/Home
• Twitter http://apiwiki.twitter.com/REST+API+Documentation
• Flickr http://www.flickr.com/services/api/

Regards.

Just my 0.02$ :

I would pick up SOAPjr: http://soapjr.org/
This is simplified SOAP protocol and realized through JSON.

Why:
1. JSON-rpc is too simplified, I would prefer more strict way doing things.
2. XML - is too heavy and not so comfortable to work with.

[Aly]

It's just my opinion which won't be reflected on API selection:

While SOAPjr is not so famous like SOAP, it's lightweight and easy to use, doesn't need overhead processing, due to it's based on JSON, not XML.

With REST, there is no batch / multicalls, not specified standard issues like called invalid method, or wrong params are sent e.t.c. everything is specific to application. (that's why there are diggtoolkit, PEAR:flickr API and others)

I barely imagine how to use REST not over HTTP?! because nowadays pure REST mostly means POX over HTTP..


P.S. This vote doesn't mean that there won't be other RPC's. It's just which will be the first

[Wolfgang]

Was to late because Vote is closed.
Anyway my Vote for JSON-RPC. 2nd choice would have been REST.

Why:
- It is pretty simple to use
- JSON and JSON-RPC are more and more supported and used
- XML has a larger overhead
- Given, that the API is just about exchanging data without any presentation, JSON can be used easily by any client/frontend app
- Looking especially to WEB 2.0 application design, JSON seems to be the winner simply because of Javascript on the clientside

[Alexei]

Thanks for participating in the voting! It was decided to implement JSON-RPC!

The work is already in progress.Stay tuned!

[nmail_uk]

Good to hear this is progressing, however will XML be an option added at a later date?

[Alexei]

Good to hear this is progressing, however will XML be an option added at a later date?

XML (or any other format) can be added easily in the future. We are trying to make the framework as flexible as possible.

[nelsonab]

I think the more important question now is what will be exposed via the API and what will those interfaces look like? For instance if rev one allows to pull data, but does not allow me to pull a range of data or there was no review regarding what the API allowed I think it would be a missed opportunity.

[Alexei]

I think the more important question now is what will be exposed via the API and what will those interfaces look like? For instance if rev one allows to pull data, but does not allow me to pull a range of data or there was no review regarding what the API allowed I think it would be a missed opportunity.

I absolutely agree. Actually we are doing some sort of code refactoring in order to make
the underlying API code work for both the API and the GUI itself. It will ensure that we have no code duplication and also guarantee much better (stable, fast) code at the end.