BiBiServ2 - aCMs

If you're not familiar with using REST webservices you should have a closer look to our webservice related webpage.

aCMs has the following functions : Select a function to adapt following short developer guide.

Provided functions/methods (parameters and datatypes)

A function provides 4 public REST methods (request, response, status and statuscode) as described in the introduction before. The table below gives an overview about the name, the supported http command, the accepted and produced mime-type.

name	type	consumes	produces
request	POST	application/json	text/plain (job-id)
response	POST	text/plain (job-id)	depends on tool typical: text/plain
status	POST	text/plain (job-id)	text/plain (code + description)
statuscode	POST	text/plain (job-id)	text/plain (statuscode)

The parameters and supported data types for each function are the same as for the browser based interface.

Input

Input are supported in two different ways. The content can be given as argument or as (Amazon-S3) URL. For Amazon-S3 there are three additional parameters.

name	description
accesskey	AWS access key for an Amazon S3 account
secretkey	AWS secret key for an Amazon S3 account.
sessionkey	AWS session token for temporary/session based account credentials.

AWS-S3 support for REST webservice is currently in a non stable status and may working or not.

RNA family (acms_input_rna_family) of type ToolDependentRepresentation.

Example Usage

We use cURL on the cmdline for an example usage of the service.

Start a new job using the request method. All necessary data - input(s) and parameter(s) - are packed into an JSON object. curl -X POST -d @[[INPUT]] http://bibiserv2.cebitec.uni-bielefeld.de:80/rest/acms/acms_function_acmbuild/request -H "Content-Type: application/json"
where [[INPUT]] contains your request data in JSON format. Use the example for an easy start. The skeleton contains all possible arguments with its constraints and doesn't work out of box but can be used as starting point to build you own individual requests. If the input is valid, a job id returned, otherwise an error/status code is returned (http status != 200). In the case of an erroneous request curl per default unfortunately doesn't return any additional information. Using the verbose parameter (-v) to get more information is extremely helpful then.
Check status of job using status or statuscode method. curl -X POST -d [[ID]] http://bibiserv2.cebitec.uni-bielefeld.de:80/rest/acms/acms_function_acmbuild/statuscode -H "Content-Type: text/plain" or curl -X POST -d [[ID]] http://bibiserv2.cebitec.uni-bielefeld.de:80/rest/acms/acms_function_acmbuild/status -H "Content-Type: text/plain" Replace [[ID]] with the id you got from a previous request. Both status functions returned current status of job. While status is more human readable, statuscode returns a machine readable 3 digit number. If the status is "600 - finished ok" you can go to the next step. While any 6xx is an non-error status that changes while the job is running, any 7xx state is an (final) error state (see list of status codes).
Get the result of your finished job using the response method. >curl -X POST -d [[ID]] http://bibiserv2.cebitec.uni-bielefeld.de:80/rest/acms/acms_function_acmbuild/response -H "Content-Type: text/plain";echo Replace [[ID]] with the id you got from a previous request. In the case the job isn't finished yet(non-error status > 600 and < 700 or error status >= 700) the status is coded into the http response.