Web API for querying specific information about zoneminder

[mastertheknife]

What kind of information are you looking to query? It shouldn't be too difficult to create another cgi-bin daemon to respond in json format.

[kylejohnson]

I'm not thinking of one in particular, however any standard (JSON, XML, whatever) would be sufficient. Your pick.

EDIT: Even better would be the ability to pick your format when you call the query ;)

[mastertheknife]

ok about the standard then. but what information do you need?

[kylejohnson]

Everything form the Monitors table should be exposed, and then the consumer of the API could decide what to query for.

[kylejohnson]

I've created an initial spec for this at https://gist.github.com/kylejohnson/10921921

[digdilem]

Looks like a good start!

Authentication? Not of critical value to me, but I can imagine knowing the ip or url (latter may contain passwords) could be a problem, exposing individual camera logins and granting control of them, bypassing zm.

Session shared from zoneminder's internal authentication? (A get out of jail free for this would be the recommend user sets up apache / htaccess auth)

[kylejohnson]

I've started working on this.

I will be implementing a RESTful API in cakephp which can return xml- and json-formatted data, as well as perform CRUD actions on the model.

[kylejohnson]

Support for querying single or all monitors, events and zones as both json and xml is complete.

[kylejohnson]

Let me know if I'm missing anything:

[digdilem]

Is there the ability to change a monitor's state? (None, record, modect
etc) - is that "Update a Monitor"?

Other than that question, it looks amazing. Thank you for adding this
feature.

On 25 April 2014 04:41, Kyle Johnson [email protected] wrote:

Let me know if I'm missing anything:

[image: 2014-04-24-234059_573x583_scrot]https://cloud.githubusercontent.com/assets/114193/2797393/6fd586c0-cc2b-11e3-9407-3a7ca1b1626a.png

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-41356407
.

[kylejohnson]

@digdilem Yes, that is 'Update a monitor'
Here is an example, where I am changing the Function of Monitor 1 to Modect:

curl -i -XPUT http://zmdevapi/monitors/1.json -d "Monitor[Function]=Modect"

[digdilem]

Brilliant, thank you.

On 25 April 2014 15:21, Kyle Johnson [email protected] wrote:

@digdilem https://github.com/digdilem Yes, that is 'Update a monitor'
Here is an example, where I am changing the Function of Monitor 1 to
Modect:

curl -i -XPUT http://zmdevapi/monitors/1.json -d
"Monitor[Function]=Modect"

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-41397604
.

[hydrogen18]

Is this issue still open? Is there an HTTP api in the latest release of ZoneMinder?

[kylejohnson]

The API is in master and will be in the next release. Just do a normal install and the api folder will be under the webroot.

On May 31, 2014 10:09:01 AM EDT, Eric Urban [email protected] wrote:

Is this issue still open? Is there an HTTP api in the latest release
of ZoneMinder?

---

Reply to this email directly or view it on GitHub:
#8 (comment)

[martin67]

Hi,

I've been running with the api for a while and I wonder if monitor state change is really working. I guess that the idea with the interface is to expose the database so that items can be added/changed etc.

So, changing a monitor mode through the api will only change the database info for the corresponding monitor table? But changing the mode through the normal way seems to do some steps more...

When I change with the API, the value in the Function column in the web interface changes to Modect and goes green (good). But the value in the source column is still yellow. And it does not seem to do any motion detection.

When I change it through the web interface, both columns goes green and the motion detection works.

My guess is that some extra logic is needed in the API or the base system must somehow check the database for updates so that the mode can be changed correctly.

[kylejohnson]

Hi @martin67

You're absolutely right. The API isn't finished yet - some of the backend logic is missing, such as restarting monitors when their state changes. What is finished is: create, retrieve, update and delete (CRUD) functionality for Monitors, Events, Zones and Config (if I recall correctly).

I haven't forgotten about the API - it'll get finished - when I (or someone else) has time. :) Fortunately most of the backend logic code is already written (in the original skin, includes/functions.php IIRC), it just has to be 'cakephp-itized'.

[martin67]

Hi,

Thanks for the clarification; I'll see if I can take a look at the code and help out.

Skickat från min iPhone

19 jun 2014 kl. 15:27 skrev Kyle Johnson [email protected]:

Hi @martin67

You're absolutely right. The API isn't finished yet - some of the backend logic is missing, such as restarting monitors when their state changes. What is finished is: create, retrieve, update and delete (CRUD) functionality for Monitors, Events, Zones and Config (if I recall correctly).

I haven't forgotten about the API - it'll get finished - when I (or someone else) has time. :) Fortunately most of the backend logic code is already written (in the original skin, includes/functions.php IIRC), it just has to be 'cakephp-itized'.

—
Reply to this email directly or view it on GitHub.

[Yanson]

Is this in the latest release? I don't see it in the web root following these instructions: http://www.zoneminder.com/wiki/index.php/Ubuntu_Server_14.04_64-bit_with_Zoneminder_1.28.0_the_easy_way

[knight-of-ni]

@kylejohnson
Do we just need to simply include everything under the web/api subfolder to the cmake & autotools scripts? I can add that as an optional install item if that is all we need to do. Let me know.

[kylejohnson]

The API gets installed corrected via cmake, but support isn't there yet for autotools.
@knnniggett In addition to installing web/api, the web/api/app/Config/ directory has a file or two that needs to be configured. Check the cmakelists.txt file for more info as I can't recall it off the top of my head.

[devinellis]

Sorry to barge in on an old thread. I've been using Zoneminder at home for a couple months now and really like the "bones" of the project (event system, modect, zones, etc) and would like to see a solid web API around it.

I think a strong API could attract people (like me) looking to hack Zoneminder for their needs, would be great for mobile development, and the current front-end could be completely replaced with a simple UI around the API.

I took a look at the CakePHP API and there's not a lot there. I also noticed that it uses some Cake-specific data formatting that I find a bit uninviting (Model names included as response objects, non-JSON POST/PUT payloads). I guess I'm just wondering, why take the approach of side-stepping the rest of the PHP code to build a separate app that just interacts with MySQL? It seems like the smarter choice would be to migrate the current PHP codebase to become the API.

I know I'm probably just scratching the surface of the project but I would like to know what the long-term goals are with the PHP code.

[kylejohnson]

Hi @devinellis

I too think that ZM's 'bones' are strong, and you're absolutely right, a good API would help significantly with (mobile) development.

The API work is now in the angular-ui branch, where I have been developing an AngularJS-based frontend which does REST calls to the API. I've been updating the API as needed, as the new UI does not use any server-side code. That branch is ready for testing, but is not complete (would love assistance from someone that has built APIs before - I'm learning as I go).

You're right, I hate how Cake adds to model name to response object. The newer API code in the angular-ui branch is using a 'Crud' plugin, which makes json responses much more sane, like what you'd expect in a modern API. I'm slowly implementing Crud in the various models and controllers, and I wish I knew of this plugin on day 1.

My goal is to move ALL of the needed PHP code to the API, while re-factoring it to make sense within CakePHP's framework. CakePHP does /a lot/ of the heavy lifting for us, so I definitely want to use it, especially for things like database interaction. Cake also support authentication, so that code will be removed from the current PHP. The rest of the code (e.g. generating videos) will be Cake-i-tized so that it can run within Cake's system and be called and used where needed.

Feel free to keep asking question and offering advice - I love to hear it.

Kyle

[devinellis]

@kylejohnson: Cool, glad you're already headed in the direction I was thinking. Is there any way we can move the Angular/API rewrite to a feature branch, and start making smaller PRs to it? Your angular-ui branch is huge, and I'd like to start leaving some feedback. I opened #744 to help clean things up.

[kylejohnson]

@devinellis Sounds good, but what are some of your specific recommendations? The angular-ui is already in a feature branch, and it makes sense (from my perspective anyway) to be able to develop the API along with the client.

[devinellis]

Since there isn't a PR for it yet there is no good place for me to leave feedback. Since we know all the UI and API changes to get this to work will be a massive diff, merging in smaller bits at a time into the feature branch would be better IMO. When it's complete the feature branch can be merged in to master. I understand needing to do API and UI work simultaneously, so maybe break it up by feature, or view?

[kylejohnson]

I think that is a good idea (split it up by feature or view). What do you propose we do with the current changes?

Kyle

[devinellis]

I guess you could start by creating a PR for what you have now, and we can move the discussion there.

[kylejohnson]

@devinellis I don't want to merge any of this code into master until we have something that is ready to be used - whatever that might mean.

[devinellis]

Exactly. So I'd suggest we create a PR of this branch into a "feature" branch (I know this is the feature branch). That way we can review what you have, and future work can be made into smaller PRs into that feature branch. When ready, we merge that feature branch into master, having reviewed it as separate PRs already.

[pliablepixels]

Hi, I am already in the process of building a mobile app - basic screens are working. More details here http://www.zoneminder.com/forums/viewtopic.php?f=32&t=23073 --> I will soon be open sourcing it (in a month or so - as soon as I get all screens done and the data models abstracted out) in the hope that others can fork and innovate. Given that you are using AngularJS, I decided to learn AngularJS and implement it in the client too .I'm not a regular coder - learning this along the way, I have some thoughts to share (feel free to correct them or tell me I am wrong):

Are there any plans of making this mainstream - aka:

1. It gets installed as part of a package install (I suspect most people are using repos/ppa and not compiling source. And those few who compile source use the dpkg route and not cmake)

2. Is it possible that as part of your automated install, you also put in instructions or a script to automatically add a CORS heads to Apache? Otherwise browsers on desktops will reject request responses to the ZM server (not a mobile problem, but a cross platform app that works on desktops will have this problem). One can use JSONP but a better approach is CORS compliance (I think)

3. Right now I am forced to use skin=xml for most views and basically trace API requests the web interface is using via httpry to see how to emulate them in the app - not an ideal approach

4. When you do install the APIs, can you also make sure it works with authentication and does not return information without auth?

[knight-of-ni]

The web API is currently in the master branch and is in testing. I'm going to close this issue out since it regards the former API feature branch and has become out of date.