We, in our working group, are using a KNIME Server and the REST API. With a growing repository we are trying to get a better overview about the settings of each workflow group, workflow and others.
To do so, I’ve built a workflow to get the properties of workflows using the REST API of the KNIME Server. For example we are using this GET request: […]/rest/v4/repository/test_rights/test1:properties?name=com.knime.enterprise.server.executor.requirements
But now I have the problem. The result of this GET request is not shown because it is not in a JSON format but in just a text/html format. But the node is just not able to show it in another format than JSON. To clarify this issue I’ve created the following example:
I start two GET requests on two different workflows.
Workflow 1: test1 - It has no executor.requirement properties
Workflow 2: test2 - The property value is “other”
The result of this two GET requests can be seen in the following graphic:
As you can see in Row2 in the Column “content-length” that the result of this GET request has a value of a length of 5 and even if I start the GET request in my browser or by using Postman
I get the following result of “other”:
I think the problem is inside the Node “GET Request” because it shows the result only in a JSON format. The other problem could be that the response of the get request is not formatted like a JSON. If it looks like this…:
{
other
}
… then the Node can show the result properly.
It would be great, if someone can look over this issue.
I’m afraid this is an open bug (internal reference SRV-3573): the return type header is application/json, but the returned body isn’t a JSON. This trips the GET Request node.
I’ve tried Ivan’s suggestion and for the properties “thisisaresttest,anothertest” I got this error message:
thank you for your reply. As you said, this is a workaround for only some cases. In fact, if there are more than one values for the property, it seems it is only possible to retrieve the first value.
yeah I guess that is the case. This approach may also fail on other characters.
I would try to outsource the task to the command line tool curl, but that also is far from elegant and OS specific…
I’ll see if I can get a status update for the bug and keep you posted here.
I’m happy to say that we were able to squeeze a fix into the server release that went online today (4.13.3, KNIME Product Downloads 2021-06 | KNIME).
If it is an option to update at some point in time, this should resolve your issue (the REST endpoint now answers with the content-type header “text/plain”).
