Rationale

To provide easy-to-use and highly reusable image processing functionalities is a central goal of ImageJ. As a result, the components of ImageJ are modular, to make them easily accessible from other Java programs. However, for programs written in other languages besides Java, the interaction becomes complicated. In order to mitigate this problem, this RESTful image server is offered as a universal interfacing layer.

Generally, existing cross-language solutions fall in two categories: in-process and inter-process. Programs using in-process solutions launch ImageJ as a child and invoke the ImageJ commands through methods such as Java native interface (JNI), compiler native interface (CNI), and runtime interpreter. In-process solutions have little overhead and less security issues, but they usually have poor portability and cannot share the ImageJ runtime instance with other processes. Programs using inter-process solutions launch ImageJ as an independent process and invoke the commands by the use of pipe, file, and network interfaces such as socket and RPC calls. Inter-process solutions are portable and allow sharing of ImageJ instances, but the communication overhead and security issues become big concerns. See LOCI's Interfacing From Non-Java Code article for a more general discussion of in-process vs. inter-process.

In order to make ImageJ more reusable, a satisfactory universal solution should be standardized. "Satisfactory" here means that the communication overhead and security concerns are relatively small, while "universal" means that a program written in any non-Java language can use the solution to talk with ImageJ without complex libraries or too much extra code.

This image server is a lightweight ImageJ wrapper that exposes all its commands through RESTful APIs. The image server has two main functionalities: I/O and module execution. It allows the caller to load/retrieve resources into/from the wrapped ImageJ instance. The caller can enumerate the available commands and run each of them with specific inputs. Since the caller only sends http requests to the image server, this solution greatly simplifies cross-language interaction. In addition, as implementing RESTful APIs has become the trend of software industry, abundant experiences are available to reduce overhead and security issues.

Making RESTful API the standard API protocol for ImageJ solves many cross-language and cross-machine integration problems. In addition, an image processing software ecosystem could be built on top of it, such that any program developed on the SciJava model could be reused by any other program through similar RESTful APIs.