I'm new to REST binding and put together my first test.
The results data-wise I'm getting is fine, but I don't understand why it has the appended \r\n and extra slash characters all throughout the response. Is this normal or what controls that? I've tried both attaching the ISD_Output stage at the receiving end of the XML Stage directly and also tried dumping the JSON output to a sequential file and using the folder stage to ISD_Output. Both do this same behavior.
The double quote characters are being "escaped" so that they are not meaningful to any shell processing the payload and will be interpreted as literal quote characters.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I do not think that is normal. I have a few REST & JSON ISD applications running with the ISD Output stage. When I test them via the URL with a web browser, I do not see any escaped characters in the results.
Choose a job you love, and you will never have to work a day in your life. - Confucius
OK, the \ escaping each double quote makes sense. How do I stop it from doing that? Like I mentioned, when I'm testing "FolderStage --> Sequential File" I don't have that in my output, but "FolderStage --> RTI Output Stage" my SoapUI response contains the escape slashes and \r\n new line characters. I guess I don't know what's doing it the RTI Stage, WISD, or my SoapUI or Internet Explorer browser. Curious if anyone has experience encountering this?
It's definitely something after the folder stage, I just don't know what. I tested with an ereplace() function after my folder stage to strip out \" and they're still there.
OK figured out a couple things and I believe have this resolved!
Decided to go with REST 2.0 instead of REST for the binding.
Fixed the error I was getting after realizing I need to change a piece of my URL path from "wisd-rest" to "wisd-rest2"
Within the Information Service Application setup at the Operations level, there's a tab "REST 2.0 Settings". There, I discovered a checkbox "Output pass through" basically telling the REST API to return the results "as-is". Sure enough, it doesn't insert the escape characters.