1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
.. |date| date::
=========================
OpenTox API Working Group
=========================
.. :Date: 30 September 2015
.. University College Dublin, Dublin, Ireland
.. https://docs.google.com/document/d/153ip9ll_pzqMphoJ4d608ujd5GuYysZcTDAODsrXsrc/edit
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
==========
|
