Is there a better way to interact with the camunda rest api than using Java RestTemplate?
Here is an example JUNIT i’m using camunda-rest-test.java.txt (1.2 KB)
The RestTemplate approach works fine but has a lot of boiler plate.
I have to convert the JSON responses into Java Object so that Jackson will map to POJO.
That’s a lot of pain given the rich API that camunda is providing.
engine-rest/task/ => JSON response represents a Array of Task
engine-rest/deployment/ => JSON response represents a Array of Deployment
etc etc etc
My approach has other problems. If the JSON model changes, it could break my implementation when upgrading to a newer release.
Does Camunda provide any client-side utililty to make this easier?
Example:
Would be nice if we could do something like this:-
CamundaRestClient crc = new CamundaRestClient(“http://localhost:8080/engine-rest”);
ProcessInstance pi = crc.startProcessByKey(myProcessDefinitionKey);
King Regards,
I’m not sure I 100% understand your question. The REST API can be accessed by anything that send a properly formatted HTTP GET, POST, or DELETE. Describe what you are trying to achieve here. What is the “client” application? Are you driving automated testing?
The is an open source (and commercial) product called “Talend ESB” that provides a wide array of tools to make interacting with web services easier. However, it has a steep learning curve, though the documentation is decent. It is a component based programming paradigm with a GUI interface. The one thing it has is tools to help you parse and map output.
The client is just a java service which calls a remote camunda engine using
the engines rest api.
The concern i have is that every rest call has a json response with
different structure.
To access the fields of the response, i want to transform the json into a
pojo.
My approach has been to use the jackson mapper together with a a
pre-defined entities that were built using http://www.jsonschema2pojo.org/
Now, if the camunda team decide to change the fields in the json response,
the pojo entities in my service will be out-of-date.
I was hoping that somewhere in the camunda library (package structure), the
json data model maps to entities.
Thank you for your suggestion.
I’m not familiar with the JSON to Pojo technology. The Camunda team, at least in the last Webinar, said they were making sure that there would be backward compatibility in the databases from 7.6 onward. Whether that applies to JSON output I can’t say, but I would hope that the response would always map to a least a base set of entities, though additional values might be added in the future. At least it wouldn’t break your stuff.
As to the “mapping” of the JSON to entities, while I don’t fully understand what you mean, I did ask if there was a WADL for the REST interface and was told there wasn’t. I thought about how one might create one automatically, which would in theory provide you with the current response structures, but never followed through on those thoughts. In other words, the structure of both requests and response can only be determined by reading the documentation, so automating, and thus protecting, the enumeration of those entities so your client can deal with changes appears to be difficult ask.
Hi @davekant,
right now there is no support of swagger or wadl files to automatically generate client. With that said, all public interfaces are guaranteed to be backwards compatible between releases. I.e. methods and endpoints are not getting removed and DTOs will preserve all existing fields. So you might get new fields in responses from API methods, but not get less information.
Does that help you?
Askar.
It answers the question, thank you.