OpenTox API Working Group

Workshop Objectives

Capture
  • service provider (developer) experiences
  • service consumer (client) experiences

Identify open issues

Resolve open issues

Unify and update API documentation

OpenTox

http://opentox.org/dev/apis/api-1.2

Focus on predictive toxicology

REST interfaces for: Compound, Feature, Dataset, Algorithm, Model, Validation, Report, Ontology, Task, Authentication and Authorisation

RDF representation

ToxBank

http://api.toxbank.net

Extensions for capturing bioassay data

Additional objects: Alert, Data, Index, Investigation, Organisation, Project, Protocol, Search, Session, Template, User.

RDF representation, ISA-Tab (http://isatab.sourceforge.net/format.html)

eNanoMapper

IDEA: http://enanomapper.github.io/API

NTUA: http://app.jaqpot.org:8080/jaqpot/swagger

IST: https://enm.in-silico.ch/api/dist

Extensions for capturing nanomaterial data

Additional objects: Bundle, Myaccount, Property, Query, Substance, Substanceowner, Pmml, Bibtex

JSON representation

Developer experiences

(De)Serialisation of large datasets/investigations

  • system/infrastructure limitations (time, memory, database/webserver size limits, ...)
  • impossible for RDF (performance of RDF parsers/serializers, markup size)
  • even JSON markup can cause problems
  • we propose CSV/TSV as data exchange format for datasets

Complexity of the one webservice/class model

  • code separation, maintenance
  • performance penalties caused by suboptimal data structures
  • performance penalties of webservices (data (de)serialisation)
  • complicated server infrastructure

Communication with external services

  • ad hoc requests for features that deviate from official API
  • reliablity/availability of external services
  • undocumented API details
  • undocumented/silent API/data format changes
  • no common strategy for conflict resolution, API or data representation updates

Local service deployment (e.g. for in house services)

  • installation far from straightforward
  • management of additional server instances
  • duplication of functionality, bloat
  • update strategy

Documentation

  • scattered/outdated documentation
  • maintenance - too many places to consider (error prone) - ideally autogenerated from code
  • ideally combined with tests (availability, API coverage, API compliance)

Client experiences

Open issues

Workflow for
  • API unification and updates
  • issue and conflict reporting/resolution
Documentation
  • location
  • format (Swagger, Wiki, ...)
  • maintenance
  • link to inventories, tests

...

OpenTox APIs

http://opentox.org/dev/apis/api-1.2

http://api.toxbank.net

http://enanomapper.github.io/API

http://app.jaqpot.org:8080/jaqpot/swagger

https://enm.in-silico.ch/api/dist

Next steps