Replies: 1 comment
-
|
We like the idea of allowing users to invoke and chain toolkit-supported API without extending the endpoints (or providing a dedicated endpoint to enable this). However, this must be addressed carefully due to security concerns (avoid eval or exec functions accessible via API). We need more feedback and use cases. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Yet another shortcoming of the proposed API is of a more general nature: the API is structured in such a way that all available operations and options must be pre-defined and be part of the formal API specification. This way, it is impossible to extend its functionality without adding new methods or changing the existing ones (the latter can break existing client applications). It is easy to notice that most CPM API methods take one molecule (encoded in some way), process it, and produce some results (a normalized SMILES, a molfile string with 2D coordinates, computed properties, etc.).
All these methods can be easily generalized as just one method (using Python notation):
where Table is class (type) representing a collection of rows and columns, each row corresponding to an element in the structures list.
The implementation must automatically determine the encoding of the input structures (SMILES, molfile string, etc.), which is trivial.
Beta Was this translation helpful? Give feedback.
All reactions