Table of Contents
1. Introduction
2. Recognition API
The Catchoom Recognition Service (CRS) is a web service that allows you to build a wide range of Image Recognition applications and services.
This document describes the Recognition API, and demonstrates how to send valid recognition queries to the CRS using REST requests. In other words, the Recognition API permits you to build a client application.
In addition to the REST APIs our Catchoom Python Library provides easy to use functions and scripts for recognition and upload of images.
The CRS Recognition API is conforming to the REST (Representational state transfer) constraints as discussed in [1]. Note that the URL of the web service may change for different versions of the recognition API. Therefore, we recommend to build the client app with this URL as a parameter.
Search allows sending visual recognition queries from client applications (such as a mobile app or your own server).
| Url format: |
|
||||||||
| Method: | POST | ||||||||
| Parameters: | Parameters are sent using multipart/form-data encoding:
For more information regarding multipart/form-data encoding consult [2]. |
||||||||
| Returns: | The service responds with HTTP status code, and, in cases of successful recognitions, with a JSON response data corresponding to the recognized items (objects). The recognized items are ordered by their relevancy, i.e. the first item from the JSON array has the highest recognition score.
The response header HTTP status codes include:
If a valid request is correctly received, and there are no internal errors, the service responds with HTTP status code “200 OK”. If no relevant items (objects) are found in the requested collection an HTTP status code “200 OK” is returned with an empty array i.e. [] in the JSON response. When relevant objects are found in the searched collection, the JSON response consists of an ordered array of all relevant items, each with the following syntax:
where:
In case of a problem, the service returns an adequate HTTP status code. Additionally, the response data may contain a verbatim JSON error message to help identifying the problem. These messages are intended solely for debugging purposes and therefore client services are not expected to parse them. |
||||||||
| Example request: |
|
||||||||
| Example responses: | Example of a response to a successful recognition:
Example of a response to a corrupt query image:
|
||||||||
| cURL example: | Recognition using query image “query_image.jpg” and collection identified by token “afe34dbe14890fac”:
|
Timestamp permits you to check whether a collection token is valid.
Tokens are used in the Recognition API and in the Catchoom Mobile Apps to specify which collection of images should be searched through. The easiest way to manage your tokens is by using the CRS web panel, but you can also do it via the Management API.
| Url format: |
|
||||||||
| Method: | POST | ||||||||
| Parameters: | Parameters are sent using multipart/form-data encoding:
For more information regarding multipart/form-data encoding consult [2]. |
||||||||
| Returns: | The service responds with HTTP status code and a JSON response data with the timestamp.
If a valid request is correctly received and there are no internal errors the service responds with HTTP status code “200 OK”. All possible status codes include:
In case the request is properly authenticated (the token is valid for the given collection) the response is as follows:
where:
In case of a problem, the service returns an adequate HTTP status code. Additionally, the response data may contain a verbatim JSON error message to help identifying the problem. These messages are intended solely for debugging purposes and therefore client services are not expected to parse them. |
||||||||
| Example request: |
|
||||||||
| Example responses: | Example of a response to a successful recognition:
Example of a response to an invalid token:
|
||||||||
| cURL example: | Check if a token is valid:
|
[1] Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine.
[2] Multipart/form-data format: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2