The Web API exposes the core SDK functions for template generation, comparison and search, via Protocol Buffers over HTTP. Client-side libraries for the Web API are available in C++, C#, Java, JavaScript, Objective-C, PHP, Python, and Ruby.

Thin-Client Hello World

You can use the Web API if you want all processing to take place on a remote server and the client machine does not have a licensed installation of the ROC SDK. You'll need a copy of the standard ROC SDK (you have it if you are reading this) to run the server, and a copy of the "roc-web" SDK for client-side development.

Launch Server:: cd bin
./roc-represent -k 5 --thumbnail ../data/roc.jpg roc.t
./roc-serve 8080 --gallery roc.t --http --log-stdout

In the above commands we construct a simple gallery of five faces from a single image and then launch the Web API server on port 8080, hosting the gallery file roc.t over HTTP and logging connection activity to the console.

In the roc-web SDK open example.html in your web browser. By default this example looks for the server at localhost:8080 so you should see the first template in the gallery as soon as the page loads. Try using data/josh_1.jpg and data/josh_2.jpg for Search and Verify.

Thin-Server Hello World

You can use the Web API on your server to recieve data transmitted by ROC software without having a licensed installation of the ROC SDK. You'll need a copy of the standard ROC SDK (you have it if you are reading this) to run the thick-client that computes and transmits templates, and a copy of the "roc-web" SDK for server-side development.

Launch Server:: export NODE_PATH=./js-commonjs && node example-server.js

Launch Client:: cd bin
./roc-track ../data/josh.mp4 http://127.0.0.1:8080/

In the above commands we launch a simple Web API server on port 8080 that prints the received templates, and then we send templates to it via roc-track.

Core Design Principles

For roc-serve one process equals one gallery equals one port.
To host multiple galleries, run multiple instances of the roc-serve process on different ports.
If you don't need a gallery, because you are only doing 1:1 comparison, specify - (single dash) as the gallery file name to roc-serve.
The functionality offered by roc-serve is also available in the API via roc_start_gallery_server.
HTTP requests should POST with Content-Type: application/octet-stream and the body being the Protobuf request message.
In web-api/roc.proto you'll observe two root message types:
1. "Request" the message the client sends to the server
2. "Response" the message the server replies to the client with
The request/response subtypes in web-api/roc.proto are named to mirror the Application Programming Interface.
Clients should first check any repose from the server to see if it is roc_error message type. If it isn't, the client can safely assume that the response type corresponds to the request type.