Pull Request

Motivation

This large pull request will bring this repo up to date with the etn-opencpu branch, with the goal of archiving that branch and bringing all server side development of the openCPU related code to this repo here and etn itself becoming a client side wrapper of this API removing the need for access to the vliz rstudio environment to use etn.

Main overview of changes

• bring over all develpment from etn-opencpu to this repo
• adapt get_acoustic_detections.R so it accepts user credentials as arguments so we can serve it over the API

Note on old commits appearing

I'm trying to preserve the log from etn, so commit history will be older than this actual repo. The advantage of this approach is that the functions here will still have complete blame history, but it does add complexity.

Next Steps

Testing

A testing suite for the API still needs to be selected and implemented.

Where should tests live, on etn or on etnservice?

I'm thinking about tests about response time and uptime monitoring. Unit test for the functions themselves we can cover with testthat in github actions. I don't think the unit tests need to run on a schedule, but response time and uptime do.

Postman was implemented, we are uptime monitoring is currently disabled for the live-test branch because the postman tests keep failing and cause the monitor to disable. As soon as the API requests are successful at least most of the time, monitoring can resume.

• Enable postman monitor

Postman is also useful to bugfix the API calls themselves.

API Documentation

• Perhaps a wiki on GitHub would suffice?

• Postman can also do this: https://learning.postman.com/docs/publishing-your-api/documenting-your-api/

• It would be nice to have a landing page for https://opencpu.lifewatch.be with some documentation, is opencpu compatible with swagger? An emtpy issue exists: Auto generate swagger docs opencpu/opencpu#294, an example of what I'm thinking about: https://petstore.swagger.io/, swagger allows you to live demo an api in the browser.

• restRServe supports swagger: https://restrserve.org/, but it's a different framework from opencpu

Todo

get_acoustic_detections() is dependent on a number of other exported functions, these (and their tests) need to be ported as well:

• get_acoustic_detections()
• test-get_acoustic_detections.R
• list_acoustic_tag_ids()
• test-list_acoustic_tag_ids.R
• list_animal_project_codes()
• test-list_animal_project_codes.R
• list_scientific_names()
• test-list_scientific_names.R
• list_acoustic_project_codes()
• test-list_acoustic_project_codes()
• list_receiver_ids()
• test-list_receiver_ids.R
• list_station_names()
• test-list_station_names.R

Tests need to pass on the hosting side as well as on the client side. Otherwise it would be difficult to diagnose problems in the future.

On the postman side:

• test-get_acoustic_detections.js
• test-list_acoustic_tag_ids.js
• test-list_animal_project_codes.js
• test-list_scientific_names.js
• test-list_acoustic_project_codes.js
• test-list_receiver_ids.js
• test-list_station_names.js
• make sure the tests work

Testing for HTTP status code, response time lower then 3 seconds, and for the list functions; 50 random values, or if there are less then 50, all values. This could cause test failure on the long run if values are removed from the database.

The documentation needs to be updated for all ported functions, consider replacing con with credentials: #9

• create readme.md
• Update argument documentation get_acoustic_detections()
• Update argument documentation list_acoustic_tag_ids()
• Update argument documentation list_animal_project_codes()
• Update argument documentation list_scientific_names()
• Update argument documentation list_acoustic_project_codes()
• Update argument documentation list_receiver_ids()
• Update argument documentation list_station_names()
• Update argument documentation get_acoustic_detections()