The DOcplexcloud API is based on REST API principles:
- You identify resources such as jobs or attachments by a URL over the Internet.
- You perform some action with those resources based on a HTTP method (GET, PUT, POST, DELETE).
You can use this API on many platforms and in many programming languages, enabling a client to fully automate the execution of the optimization problems on the Cloud.
Much of the API is concerned with exchanging JSON data to create jobs, get their status, and delete them. There is also an API to upload input attachments for models and data and to download the results and logs.
Using the HTTP protocol, the content of these attachments is streamed back and forth between the client and the DOcplexcloud servers. In some examples, we send and receive files for the sake of simplicity. This is of course useful, but typical applications will also stream content from different sources (objects in memory, databases) without creating intermediate files or a large buffer in memory. This is particularly important to improve the performance and the memory footprint of your application. If your client is in Java, you can find an example in Streaming Data in Java.
The API also leverages the compression of HTTP data. Clients can indicate that they accept compressed results by adding
Accept-Encoding: gzip as a HTTP header in requests. Clients can also send compressed messages and attachments by setting the
Content-Encoding: gzip header with the compressed attachment streams and messages.
The Java client manages this automatically: It compresses attachments and messages on the wire when necessary, and it will decompress results as well. The compression/decompression is performed dynamically on the data streams to be fully transparent.
JSON is the preferred data format to integrate DOcplexcloud services, and it can be a verbose format. Fortunately, the transferred data size can be kept under control with the stream compression, while keeping the flexibility of the JSON format. In addition, input data and results are typically sparse and developer should take care to exchange significant data only, see OPL model input and output.