Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

EGI AppDB REST API v1.0

From EGIWiki
Jump to navigation Jump to search

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:

  • count (number) : the count of the entries found in the applications database. In case of paging, where only a subset of the results gets returned, the attribute is left unaffected.
  • pagelength, pageoffset (numbers) : paging data in case the response is a list of resources. More information follows in the next section.
  • datatype (string) : an identifier for the resource data that is enclosed in the response as defined in the XML schema.
  • type (string) : the type of the response. Possible values are:
    • list: A collection of references to entries in the applications' database. In order to obtain the referenced entry, a request should be made using the entry's id.
    • entry: Detailed information about an entry in the applications' database. Paging is never used for this type of response.
  • version (number) : The version of the API that was accessed.
  • error (string) : If an error occurs, this attribute will contain the error message.
  • host, apihost (strings) : the URIs of the host that provided the data and API access, respectively.

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:

  • pagelength : defines the count of entries to be displayed in each page.
  • pageoffset : defines the position in the list of entries from which the page will start.

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. For more information on the syntax, please refer to FAQ item #13 at the AppDB portal.

API Reference

Application List

  • Resource: applications/
  • Type: list
  • Datatype: application
  • Schema: application
  • Filtering: yes
  • Public Operations: PUT POST
  • Authenticated Operations: PUT POST

Application Entry

  • Resource: applications/
  • Type: entry
  • Datatype: application
  • Schema: application
  • Filtering: N/A
  • Public Operations: GET
  • Authenticated Operations: DELETE

Moderated Application List

Application Publication List

Application Publication Entry

Application Tag List

Application Tag Entry

Related Application List

Application Rating Report

External Application Rating Report

Internal Application Rating Report

Application Rating List

Application Rating Entry

Application State History List

Application State History Entry

Bookmarked Application List

Bookmarked Application Entry

Editable Application List

Owned Application List

Associated Application List

People List

Person Entry

Regional Information List

Application Category List

Discipline/Subdiscipline List

Middleware List

Application Status List

VO List

VO Entry

User Role List

Available Tag List

Contact Type List

Application Filter Normalization

Application Filter Reflection

Person Filter Normalization

Person Filter Reflection

VO Filter Normalization

VO Filter Reflection

Dissemination Log List

Dissemination Log Entry