New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web API for querying specific information #8
Comments
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. |
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 ;) |
ok about the standard then. but what information do you need? |
Everything form the Monitors table should be exposed, and then the consumer of the API could decide what to query for. |
I've created an initial spec for this at https://gist.github.com/kylejohnson/10921921 |
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) |
Support for querying single or all monitors, events and zones as both json and xml is complete. |
Is there the ability to change a monitor's state? (None, record, modect Other than that question, it looks amazing. Thank you for adding this On 25 April 2014 04:41, Kyle Johnson notifications@github.com wrote:
|
@digdilem Yes, that is 'Update a monitor'
|
Brilliant, thank you. On 25 April 2014 15:21, Kyle Johnson notifications@github.com wrote:
|
Is this issue still open? Is there an HTTP api in the latest release of ZoneMinder? |
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 notifications@github.com wrote:
|
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. |
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'. |
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
|
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 |
@kylejohnson |
The API gets installed corrected via cmake, but support isn't there yet for autotools. |
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. |
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 |
@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. |
@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. |
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? |
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 |
I guess you could start by creating a PR for what you have now, and we can move the discussion there. |
@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. |
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. |
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:
|
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. |
Monitor packetqueue
==8109==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fab9b156480 at pc 0x7fabaebef57b bp 0x7fab9b154640 sp 0x7fab9b153df0 READ of size 32 at 0x7fab9b156480 thread T2 #0 0x7fabaebef57a (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x561c0a9e24eb in bool std::__equal<true>::equal<char>(char const*, char const*, char const*) /usr/include/c++/8/bits/stl_algobase.h:814 ZoneMinder#2 0x561c0a9dfa8e in bool std::__equal_aux<char*, char*>(char*, char*, char*) /usr/include/c++/8/bits/stl_algobase.h:831 ZoneMinder#3 0x561c0a9dd982 in bool std::equal<__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > , __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::c har_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >) /usr/include/c++/8/bits/stl_algobase.h:1049 ZoneMinder#4 0x561c0a9cf75a in RtspThread::Run() /root/zoneminder/src/zm_rtsp.cpp:411 ZoneMinder#5 0x561c0a9df6e9 in void std::__invoke_impl<void, void (RtspThread::*)(), RtspThread*>(std::__invoke_memfun_deref, void (RtspThread::*&&)(), RtspThread*& &) /usr/include/c++/8/bits/invoke.h:73 ZoneMinder#6 0x561c0a9dd4ae in std::__invoke_result<void (RtspThread::*)(), RtspThread*>::type std::__invoke<void (RtspThread::*)(), RtspThread*>(void (RtspThread:: *&&)(), RtspThread*&&) (/root/zoneminder/cmake-build-debug-remote/src/zmc+0x1544ae) ZoneMinder#7 0x561c0a9e6a1a in decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> > ::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/8/thread:244 ZoneMinder#8 0x561c0a9e698d in std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> >::operator()() /usr/include/c++/8/thread:253 ZoneMinder#9 0x561c0a9e68ff in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> > >::_M_run() /usr/include/c++/8/threa d:196 ZoneMinder#10 0x7fabaca57b2e (/lib/x86_64-linux-gnu/libstdc++.so.6+0xbbb2e) ZoneMinder#11 0x7fabae50dfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 ZoneMinder#12 0x7fabac7354ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
I am tracking this work in my fork, in the 'api' branch.
The text was updated successfully, but these errors were encountered: