EGI AppDB REST API v1.0

From EGIWiki
Jump to: navigation, search

Contents

Introduction

This document is intended for developers who want to write applications that interact with the AppDB API over the web using HTTP commands following the REST paradigm. The API is located at http://appdb-pi.egi.eu and it allows information retrieval and modification from third party applications without having to reside on the rich user interface of the AppDB portal. Thus one is given the opportunity to design one's own front-ends.

Getting started

Operations

Starting with version 1.0, the AppDB API features write access as well, by supporting HTTP verbs such as PUT, POST, and DELETE. Verb mappings to data operations follow a CRUD convention, as depicted in the following table:

Operation

HTTP Verb

Create PUT
Read GET
Update POST
Delete DELETE


The API also supports the Listing operation (CRUDL extension), by passing the parameter listmode=listing in the querystring when performing a GET request. Please note that in order to simplify the access model, Update operations are always partial, meaning that properties of the resource that is being updated which are entirely missing from the representation, are ignored (i.e. their state in the backend does not change). Therefore, in order to unset/remove a property, one has to explicitly specify it as NULL, provided that this is permitted. This is the reason why Create and Update CRUD mappings are inverted with regards to what is usually accustomed. Finally, the API also supports the OPTIONS HTTP verb, which returns a list of the operations that are permitted, in principle, for the resource in question.
The base URI for this version of the RESTful API is

http://appdb-pi.egi.eu/rest/1.0/

and requests must be followed by at least one resource name, which may be followed by one or more optional sub-resource names, separated by slashes, as in the examples given bellow:

http://appdb-pi.egi.eu/rest/1.0/applications/
http://appdb-pi.egi.eu/rest/1.0/applications/50/

Response types

Because the API conforms to the REST paradigm, responses to all CRUD operations are always XML document representations of the resource in question. These documents are described by schema files which reside publicly in the web server. All the XML documents are enveloped in a common root element named appdb with attributes that describe request status, such as paging, or errors. These attributes are:

Paging and Filtering

The paging mechanism that the API provides, as far as Read/Listing operations are concerned, can be used through two query parameters (if allowed) and can be displayed in the attributes of the root element of the response XML document. The query parameters are:

So if the client wants a list of 50 entries and wants to display the first 10, then the parameters should be set as page length=10 and page offset=0. To view the next 10 entries it should change the page offset to 10, for the next 10, it should set page length to 20, etc. One must remember that paging is not valid for all resources, as documented in the query parameters section in the API reference. A final note about paging is that if the client hasn't explicitly enable paging, then the server will default to a preset paging value, in order to reduce load; this value can be retrieved from the relevant attributes of the response’s root node. If the paging parameters were set by the client but the page length exceeds that of the server's default maximum value, then the later is used. Otherwise the page length set by the client will be used.
Moreover, some of the API’s resources support filtering when doing Read/Listing operations; filter expressions may be passed in the querystring by assigning a value to the flt parameter, in order to retrieve just the subset of data that match certain criteria. These filter expressions are strings that may range from simple keywords to complex queries. They are search arguments which will be matched to results that are deemed relevant in the scope of the search target. These expressions can range from the simple and obvious space separated keyword list, to complex operator and field specific queries. In particular, filter expressions are composed of one or more keywords, optionally prefixed by operators and/or specifiers. The syntax in BNF is:

<expression> ::= <keyword>*
<keyword> ::= [<operator>][<specifier>:]some_string
<operator> ::= [<context_operator>]<comparison_operator>
<context_operator> ::= &
<comparison_operator> ::= = | * | ~ | $ | <[=] | >[=] | +[=|*|~|$|<[=]|>[=]] | -[=|*|~|$|<[=]|>[=]]
<specifier> ::= <related_entity>[.property_name] | property_name
<related_entity> ::= application | person | vo | middleware | country | [sub]discipline

Rules are as follow:

Please note that in this case, the keyword NULL takes on the special meaning of a nil value

Optionally prefixing the "=" operator as well, will make the comparison operator non-strict.

Consider the following examples when searching for software:

cms atlas

will return a software item named "CMSSW", another named "ATLAS", another belonging to the "atlas" VO, etc.

cms atlas +greece

will return only the subset of the previous example's results that actually mention Greece (e.g. in the description, or by having a researcher from Greece in their contact list, etc.)

cms atlas -greece

will return only the subset of the first example's results that do not mention Greece

vo:biomed

will return software that belong to the VO's that contain biomed in their name or description

=vo.name:biomed

will return software that belong to the VO named "biomed" only

<dateadded:2011

will return software that have been registered before the year 2011

>=name:x

will return software whose names begin with "x","y", or "z"

person:"john doe"

will return software that has someone whose name contains "john doe" listed as a contact

discipline:physics +tag:portal

will return software that are filed under disciplines that are related to physics, and that are tagged as portals

For a list of possible specifiers, you can look up the /filter/reflect subresource of any searchable resource (e.g. /applications/filter/reflect), or you can also try using any search box in the portal, and check out the autocompletion list.

Authenticated Access

Some or all operations on certain resources may require authentication, as indicated in the API Reference section below. In order to authenticate, the following parameters must be provided in the query string, or POST fields accordingly:

When creating a client application that makes authenticated use of the AppDB API, developers have a choice of either

The first case would apply best to client applications that share the same user base with the AppDB (e.g. NGI versions of the portal), while the second case would be preferred by client applications that have a different user base (e.g. external projects which wish to collaborate). The use of an API key permits the identification of the source of API requests in both of the above cases, and adds an extra level of security by allowing access only from specific sources via netfilters. Defining netfilters for an API key is not required, but it is strongly suggested, since they can help safeguard its use. Special care should be taken by client applications that make client-side API calls (e.g. web pages with javascript via XHR), since the API key would then probably be visible to the public. In such cases, it is advised to use a proxy which routes API calls and append the API key server-side.

Sample Use Cases

https://appdb-pi.egi.eu/rest/1.0/people/profile?username={username}&passwd={password}&apikey={apikey}

with the API key hard-coded in the PHP code, or read from a server-side config file. The AppDB server returns the XML representation of the user's profile, which contains its user ID. The Martian website then stores the user ID and the MD5 sum of the password in the server session and/or in a client-side cookie, and the log in procedure is complete. All future authenticated calls to the AppDB API from the Martial website are then done either though PHP server side cURL calls in a similar fasion, where the user ID and password are retrieved from the session information, or via javascript XHR proxied through the Martian server in order to securely append the API key, if the website uses AJAX.

https://appdb-pi.egi.eu/rest/1.0/applications?username=grid4martians&passwd={password}&apikey={apikey}

providing XML representation of its own applications, in order to register them with the EGI AppDB, and associates the returned IDs with the entries in its own backend. It also issues a GET operation to

https://appdb-pi.egi.eu/rest/1.0/applications?listmode=listing

to get a list of all the applications registered in the AppDB, and then issues multiple GET operations to

https://appdb-pi.egi.eu/rest/1.0/applications/{id}?username=grid4martians&passwd={password}&apikey={apikey}

one for each of the application IDs returned by the listing, in order to migrate EGI applications into their own backend. Now, each time one of its users uses the project's website to modify an application, the server issues a POST operation to the AppDB API, in order to synchronize the changes.

https://appdb-pi.egi.eu/rest/1.0/applications/{id}?username=grid4martians&passwd={password}&apikey={apikey}

Moreover, it periodically checks the AppDB by issuing a GET operation when an application is displayed in their portal, in order to check if the information contained in their backend is up-to-date.

API Reference

Below you may find an exhaustive list of the resources v1.0 of the AppDB RESTful API offers. Details and documentation about a resource's representation may be found as XSD annotations inside the appropriate schema file, under the schemata base resource. Note that when performing POST operations, the representation must be passed as a URL-encoded string in the query-string under the parameter data, whereas when performing PUT operations, the representation must be passed as a normal text stream. Representations passed to PUT/POST operations must be enclosed within an appdb:appdb root element, with the appropriate XML namespaces declared, the same way that responses are; nevertheless, this will be omitted in all following examples, in order to reduce clutter.
Also note that since all Update (POST) operations are partial, XML elements that represent properties with a cardinality 0..* must be either

This way, it is possible to perform modifications to a resource's properties without having to re-declare all instances of other properties with 0..* cardinality, lest they were to be erased. Properties of 0..1 cardinality may also be declared NULL in a similar fasion, in which case their value in the backed becomes undefined.
Moreover, one should also note that the response of all PUT/POST/DELETE operations equivalent to that of a GET operation, with the state of the resource

This way, it is possible - as well as advised - to differentiate the response with the input to such operations, in order to verify that the result is what was intended, since properties that are malformed or invalid will not break the operation, but rather be ignored, as long as the representation is well-formed (i.e. passes the XSD compilation).

Application List

List of all application entries registered in the database

Examples:

will return all applications that are related to Greece

where {data} is

<application:application id="123">

<application:description>some new description</application:description>

</application:application>

will update application with ID 123 setting it description to "some new description" and leaving all other properties as-is.
Similarly, providing

<application:application id="123">

<discipline:subdiscipline xsi:nil="true" />

</application:application>

as {data} will remove all subdiscipline associations from the application, and providing

<application:application id="123">

<discipline:discipline id="1"/>

<discipline:discipline id="5"/>

</application:application>

will replace the list of associated disciplines of the application with ID 123, with the disciplines with IDs 3 and 5 ("Life Sciences" and "Earth Sciences" respectively)

Note that providing {data} as

<application:application id="123">

<discipline:discipline xsi:nil="true" />

</application:application>

to a POST operation will result in an error, since discipline elements are not defined as nillable in the schemata, meaning that all application entries must have at least on discipline in their complete representation.


Finally, doing

with {data} defined as

<application:application tagPolicy="0">

<application:name>MyGridApp</application:name>

<application:description>my grid application</application:description>

<application:abstract/>this is a grid application which performs task X</application:abstract>

<application:category id="1" primary="true"/>

<application:category id="2" primary="false"/>

<discipline:discipline id="1"/>

<application:status id="6"/>

<vo:vo id="951"/>

<application:contact id="189"/>

<application:contact id="190"/>

<publication:publication >

<publication:title>Evidence of Y using novel method X</publication:title>

<publication:url>http://linkto.my.pub</publication:url>

<publication:conference>X developments 2012</publication:conference>

<publication:proceedings/>

<publication:isbn>ISSN 0000-0000</publication:isbn>

<publication:startPage>592</publication:startPage>

<publication:endPage>597</publication:endPage>

<publication:volume>18</publication:volume>

<publication:publisher/>

<publication:journal/>

<publication:year>2012</publication:year>

<publication:type id="1">Full Paper</publication:type>

<publication:author main="true" type="internal">

<person:person id="189"/>

</publication:author>

<publication:author type="external">

<publication:extAuthor>John Doe</publication:extAuthor>

</publication:author>

</publication:publication>

<middleware:middleware id="1">gLite</middleware:middleware>

<middleware:middleware id="5">MyGrid</middleware:middleware>

<application:tag>methodX</application:tag>

<application:tag>countryZ</application:tag>

</application:application>

will add a new application to the database, with the following properties:

Application Entry

Detailed description of a specific application entry

Moderated Application List

List of applications that have been moderated some some particular reason, and thus hidden from public view until the issue gets resolved.
Administrative access only.

Examples:

where {data} is

<application:application id="123">

<application:moderationReason>copyright violation</application:moderationReason>

</application:application>

will moderate the application with ID 123, providing "copyright violation" as the reason

Application Publication List

List of scientific publications related to an application entry.
Publications can be individually managed from this resource (and its sub-resources), or collectively defined directly from application/{id} resources

Application Publication Entry

Detailed description of a publication related to an application entry

Application Tag List

List of tags applied to an application entry.
Tags can be individually managed from this resource (and its sub-resources), or collectively defined directly from application/{id} resources

Examples:

where {data} is

will apply the tag "C++" to the application with ID 123

Application Tag Entry

Detailed description of a tag applied to an application

Related Application List

List of applications related to an application entry

Application Rating Report

Report on all user ratings of an application entry

External Application Rating Report

Report on user ratings of an application entry made by registered users

Internal Application Rating Report

Report on user ratings of an application entry made by anonymous users

Application Rating List

List of user rating entries applied to an application entry

Application Rating Entry

Detailed description of a rating entry applied to an application entry

Application State History List

List of previous states of an application entry.
Administrative access only.

Application State History Entry

Detailed description of a previous state of an application entry.
Administrative access only.

Bookmarked Application List

List of application entries bookmarked by a user

Examples:

will return all application entries with a discipline related to chemistry and which have been bookmarked by the user with ID 123

Bookmarked Application Entry

Detailed description of an application entry bookmarked by a user

Examples:

will delete the application with ID 111 from the list of bookmarked applications of the user with ID 123

Editable Application List

List of application entries that a user has permission to edit

Owned Application List

List of application entries that a user holds ownership of

Associated Application List

List of application entries that a user is associated to, as a member of the application's contact list

People List

List of users (people) that have registered with the database

Examples:

where {flt} is the URL-encoded representation of

>=registeredon:2012-02 +=vo.name:SEE -country:Greece

will return a list of all people who have registered after or in Feb 2012, have a relation to the VO named SEE and that are not related with Greece

Person Entry

Detailed description of a user entry

Regional Information List

List of countries, regions, and service providers participating in the EGI project and available to application and user entries

Application Category List

List of category types available for application entries

Discipline/Subdiscipline List

List of discipline and subdiscipline types available for application entries

Middleware List

List of grid middlewares supported by application entries and VOs

Application Status List

List of status states available to application entries

VO List

List of VOs registered with the EGI Operations Portal and available to application entries

Examples:

where {flt} is the URL-encoded representation of

application:CMS +description:CERN

will return the list of VOs that contain the word CERN in their description, and that are related to any application that mentions CMS in any of its properties

VO Entry

Detailed description of a VO registered with the EGI Operations Portal and available to application entries

User Role List

List of user roles available, which define base user privileges

Available Tag List

List of all tag entries that have been attached at least once on any application entry

Contact Type List

List of contact types available to user contact information entries

Application Filter Normalization

Validates and normalizes a filter expression for application searches, defined by the querystring parameter flt

Application Filter Reflection

Returns a nested representation of the filtering expression specifiers available to application searches

Person Filter Normalization

Validates and normalizes a filter expression for user searches, defined by the querystring parameter flt

Person Filter Reflection

Returns a nested representation of the filtering expression specifiers available to user searches

VO Filter Normalization

Validates and normalizes a filter expression for VO searches, defined by the querystring parameter flt

VO Filter Reflection

Returns a nested representation of the filtering expression specifiers available to VO searches

Dissemination Log List

List of dissemination messages that have been dispatched to registered users.
Administrative access only.

Dissemination Log Entry

Detailed description of a dissemination message that has been dispatched to registered users.
Administrative access only.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export