Technical research: REST API

tdmore-dev / tdmore

In silico evaluation of precision dosing

https://tdmore-dev.github.io/tdmore/dev

GNU Affero General Public License v3.0

3 stars 1 forks source link

Technical research: REST API #10

Closed rfaelens closed 6 years ago

rfaelens commented 6 years ago

Many options exist for providing a RESTful API with an R backend. We should investigate which one is most appropriate for the integration with KWS.

Current status: check out plumbr, write a test API and check how plumbr works:

complex JSON objects in POST content
Returning a named list
Returning an error
Can you enable HTTP Basic Auth?

rfaelens commented 6 years ago

Google search yields a couple of different APIs: Plumber: https://rviews.rstudio.com/2018/07/23/rest-apis-and-plumber/ https://www.rplumber.io/docs/rendering-and-output.html#response-object

This sounds like quite a mature option. The API definition is clean, and can be customized easily. The documentation explains how to host on cloud services, or even on Docker/Docker Compose with load balancing. The package is well maintained (last commit 12 days ago), and seems overall mature.

rfaelens commented 6 years ago

OpenCPU positions itself as a cloud provider for R packages. The API is complete and very detailed, although also a bit more rigid. https://www.opencpu.org/api.html It seems to be geared towards building web applications (with JS -> R), rather than web services for B2B.

However, we can use OpenCPU as inspiration to define our own REST API, e.g. with regards to stateless communication or async comms.

rfaelens commented 6 years ago

http://rapache.net/manual.html rApache is a plugin for Apache. It loads R as a shared library, starts it and executes a specific script. In a sense, this is CGI for R. It seems to be very geared towards building your web app (with HTML), rather than restful interface.

rfaelens commented 6 years ago

Finally, we have Fiery. Fiery is a light-weight webserver for R. Again, there is little support for RESTful method mapping, and requires us to do a lot ourselves. https://github.com/thomasp85/fiery

rfaelens commented 6 years ago

DeployR is the Microsoft solution. No-go, as this needs to be open sourced in the end...

rfaelens commented 6 years ago

It seems the choice will be between OpenCPU and Plumber.

https://www.quora.com/How-do-plumber-and-OpenCPU-compare-when-it-comes-to-deploying-ML-models @JeroenOoms mentions the installation is stable, because it is deployed from pre-built packages. In my mind, these two are unrelated... He does mention a lot of cool functionality to ensure foreign code is sandboxed, and does not crash the server. Cool, but not required for us. Plumber is single-threaded (not ideal), but maps better with creating a RESTful API.

In the end, we choose to use Plumbr. Server deployment can use Docker Compose to spread across multiple Plumber processes, or even Docker Swarm to load-balance across multiple hosts.

rfaelens commented 6 years ago

We should now create a proof-of-concept for Plumber. To decide better on the specific API, we should also do some performance tests.