Eric, I might be misunderstand you, but the example you provided is:
A full REST/HTTP response which has request and response payloads, and the response itself should have three constituent parts: - Start Line, - Headers, and - Body Now, I cannot see your actual output and it is client log/trace dependent, but from the example I copied and pasted: *Date →Mon, 21 Jan 2019 16:41:09 GMTContent-Type →application/json;charset=utf-8Content-Length →143Server →Jetty(9.4.11.v20180605)http://abcdef00009d15:8080/ignite?cmd=get&key=107&cacheName=default&destId=8b13ac15-f503-4f4a-ab1f-a7fc3ce93596 <http://abcdef00009d15:8080/ignite?cmd=get&key=107&cacheName=default&destId=8b13ac15-f503-4f4a-ab1f-a7fc3ce93596>{"successStatus":0,"affinityNodeId":"8b13ac15-f503-4f4a-ab1f-a7fc3ce93596","sessionToken":null,"error":null,"response":"{\"name\":\"Ceasar\"}"}* It sure looks like the body is: *{"successStatus":0,"affinityNodeId":"8b13ac15-f503-4f4a-ab1f-a7fc3ce93596","sessionToken":null,"error":null,"response":"{\"name\":\"Ceasar\"}"}* And that HTTP body when using the supplied Content-Type encoding header ( application/json;charset=utf-8) (including the back slash characters) is a legitimate JSON. So an application that is parsing the REST HTTP response body will correctly parse it as such (a visual representation of a JSON DOM): { "successStatus": 0, "affinityNodeId": "8b13ac15-f503-4f4a-ab1f-a7fc3ce93596", "sessionToken": null, "error": null, "response": "{\"name\":\"Ceasar\"}" } Where the "response" element is a correct string (protected by some internal noise that might interfere from the value being properly seen as a string. I copied the body from your example (i.e. the text shown above in monotype font) into https://jsonlint.com/ to validate this body is JSON (I also used Eclipse and Atom also to validate it and give me the pretty-print view of the DOM). I agree with you, it would be nice if in addition to the entire REST Response Body being JSON, that the internal response element inside the body could also be fine-grained JSON, but alas not to my knowledge. Cheers, Glenn On Mon, Jan 21, 2019 at 3:01 PM EMCox <[email protected]> wrote: > Glenn, > > I don't want to or need to interogate the JSON being stored. I just need it > to be returned as valid JSON. > > If you try to parse a simple response as i show with the escape characters > it will fail JSON validation and does. > > I just need the dynamic JSON to be valid in the response, stored in > whatever > form. I just need the cache to leave it alone and I'll ensure it is valid > going in to the cache. The committing of the data object to the cache > should > not change what is saved in any way. Here ignite is actually changing what > I > commit to the cache. I want ignite, the cache, to leave it alone and return > only what I put in. > > Perhaps Ignite needs a second set of ADD and GET that returns the JSON > structure as is and doesn't have all of the other fields and response:"" > object. I just want the JSON body that I submitted to the cache to be > returned. > > It doesn't sound like Ignite supports this basic pattern. > > Thanks much for your thoughts. > Eric > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
