Impossible to extend its functionality without adding new methods

[vcnainala]

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):

```jsx
def compute(structures: list[str], function_codes: list[str], options: dict[str, str]) -> Table
```

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.

• Autodetect encoding of the input structures (SMILES, molfile string, etc.)

[vcnainala]

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.