A typical situation for input data is a list of identifier, e.g. CompoundID1, CompoundID2, CompoundID3, in a table with 1 column and 3 rows.
At the moment the GET Ressource node is only able to handle one row in the input table. If I have a input table with more than one row, I will have to design workflows like TableRowToVariableLoopStart > GET Ressource > Loop End (connected with 2nd port of GET Ressource). A workflow with a loop is always slow.
Therefore it might be worthwhile for a new version of GET Ressource that this node is able to handle more than one row in a input table.
Secondly, it might to useful to define the body of an http address in GET Ressource. E.g. the address for CompoundID1 is http://www.xxxxx.com/compounds/CompoundID1. CompoundID1 is the input from the predecessor and http://www.xxxxx.com/compounds is defined once in GET Ressource. That spares one a further Java Snippet to generate the http address.
thank you for bringing up this topic. We did not support an in-node-looping like this on purpose, because we might get in trouble when handling failing requests (since we cannot undo previous requests if one in the sequence fails).
On the other hand, we might provide such nodes for the safe methods (GET, OPTIONS, HEAD) or at least for GET (which is probably the node used most). This will take a while, however, since it requires some refactoring.
As for the URL building, I would still prefer to assemble the URLs in a separate node to keep the functionality of the submitter as lean as possible. URL assembly can be done easily with a String Manipulator without scripting. Or is there something speaking against that?
In my opinion it is worthwhile to support multiple rows as input for the GET Resource node . You will make a lot of users happy. Any comments from other KNIME users are wellcome.
URL building outside the REST nodes is no problem, e.g. String Manipulator. There are different philosophies behind node designs - nodes with complex configurations vs. simple (less complex) nodes that are easy to handle/configure. There is no right or wrong.
I found the GET Resource (Batch) node in the nightly build and it works fine for me. Now one can handle more than one row as input queries. Many thanks!
I am happy the batch nodes work as expceted. I have added batch conversion support now too so that you can convert the representation as usual (with the Read REST Representation Node).
Please let me know if there is something missing about this feature.
In principle it works. Thanks.
But have a look at the output of the Read REST Representation node in the attached workflow. In the column "smiles" there is a "56" as cell value, but the XML column there is the value "<smiles>COc1ccc2[C@@H]3[C@H](COc2c1)C(C)(C)OC4=C3C(=O)C(=O)C5=C4OC(C)(C)[C@@H]6COc7cc(OC)ccc7[C@H]56</smiles>" - see output of GET Ressorces (Batch) node.
BTW: I am not sure if this is a correct smiles code, but it is a string that should fit into a string cell.
Best Regards, Frank
thanks for reporting this issue. If have fixed this bug, it should work with the new version (after next nightly build - due to this I will postpone going to the stable build until next monday to make sure there are no new bugs).
the problem is solved. Thanks!