kylejohnson
commented
9 years ago Hey there. So -
a) As I've already mentioned earlier, its critical the API ties into the same php auth ZM is using in opt_auth - an open API is unusable and insecure (I'm hoping you tell me I can fix it easily)
Let us be careful with our words here. While the API does not have any authentication currently, it will. That said, it will probably, almost certainly, not be the "same php auth" that the current frontend is using.
b) Mobile devices have memory restrictions, so http://zmdevapi/events.json can be a problem if the list is large. And this list can easily be very large. I'd recommend the following:
Completely agree. In fact, this functionality is already there, but it is not documented nor intuitive. I'll need to document it - my bad.
c) There is no tie in with monitors and events. There should be.
Well, maybe there should, maybe there should not, at least in the way you're thinking (that is, a monitor recurses and finds all of its children)
You can currently find all Events which belong to a MonitorId, but you can not currently find all Events which are children of a Monitor.
Based on b) above, you can filter events by MonitorId (e.g. GET /api/events/MonitorId/3/MonitorId/4.json (I think)). Not sure if this is documented - probably not - my bad.
d) The monitor list should return a live view URL as something I can construct as an img-src
I've added that recently, or so I thought. If not, I agree. On second though, perhaps it was 'base event path' that I added.
e)
See above
f) As these fields are a single entity in the database, they're going to be a single entity in what is returned. It is the client's job to format the timestamp into a date + time, or whatever else they want. Not all clients may want this feature, so we remain neutral.
server notes
I'll need to document my experiences, but what you are experiencing is not what I was. I have, many times, reinstalled from CMAKE and then had a useable API immediately afterwards.
Part of the issue may be that you have your webroot under an alias (/zm) instead of under a virtual host (/). I access my server at http://server/, and the api is directly under that at http://server/api.
Also, I use nginx, so am hesitant to include web server configuration as part of the API. Just try hosting your site under a virtual host under /.
Hope this helps!
pliablepixels
davidsainty
I'm going to leave some more notes on how my (forthcoming) app can benefit more from the APIs. Not sure if this is the best way to do it - i.e. start an issue, so please advise if I need to present it any other way:
a) As I've already mentioned earlier, its critical the API ties into the same php auth ZM is using in opt_auth - an open API is unusable and insecure (I'm hoping you tell me I can fix it easily)
b) Mobile devices have memory restrictions, so http://zmdevapi/events.json can be a problem if the list is large. And this list can easily be very large. I'd recommend the following: b.1) Add ability to get length of events without fetching all of them. b.2) Add ability to specify a "from" and "to" so I can chunk get events in my code to preserve memory b.3) add ability to return events between a specified start date/time and stop date/time
c) There is no tie in with monitors and events. There should be. In addition to point b) above, I'd love to see events scoped inside monitors like so http://zmdevapi/monitors/1/events.json. All the operations of point b should work scoped inside a specific monitor too.
d) The monitor list should return a live view URL as something I can construct as an img-src - right now I am constructing it separately as img ng-src="{{loginData.url}}/cgi-bin/nph-zms?mode=jpeg&monitor={{monitor.ID}}&scale=100&maxfps=3&buffer=1000&user={{loginData.username}}&pass={{loginData.password}}&rand={{rand}}" - there is no tie in to the API
e) The detailed events list should also return an img-src url to view the event
f) In detailed events, please separate out time from date
Notes on your server side: a) As of today, the cmake install does not make the APIs active -- so if I am building an app that uses those APIs, pretty much no one can use it because even if they did do cmake, they need to add the API paths to apache configurations. I'd appreciate if you add that to your wiki. I added it via .htaccess - not sure if that is the right way (the APIs are unauthenticated - not sure if thats due to htaccess or not)
b) Consider adding Header set Access-Control-Allow-Origin "*" to your apache.conf to allow for desktop clients to be able to access your APIs