The default behaviour of the created REST service expects the JSON payload to be encapsulated within
{"request":
......
......
}
The thrid partyies that want to use our REST service can not make changes to produce the format I need.
I created the service using OE 11.3 devloper studio. Is there a way to have my service do the encapsulation?
Thanks, Tony.
The default behaviour of the created REST service expects the JSON payload to be encapsulated within
{"request":
......
......
}
The thrid partyies that want to use our REST service can not make changes to produce the format I need.
I created the service using OE 11.3 devloper studio. Is there a way to have my service do the encapsulation?
Thanks, Tony.
Flag this post as spam/abuse.
Hi Srinivas,
Is the opening tag {"request": ..... } a JSON standard or is it something that the OpenEdge REST application does.
Either way, the third party can not send the JSON payload with the {"request": ... } tag.
I just need to know if it's possible to 'Insert' the tag on incomming POST's.
Thanks, Tony.
Hi Srinivas,
Is the opening tag {"request": ..... } a JSON standard or is it something that the OpenEdge REST application does.
Either way, the third party can not send the JSON payload with the {"request": ... } tag.
I just need to know if it's possible to 'Insert' the tag on incomming POST's.
Thanks, Tony.
Flag this post as spam/abuse.
I could not find any reference on the web that states the JSON payload for a REST service POST must have the opening {"request": .. } tag.
I'm thinking this is an OE requirement when you want to map objects in the payload to input parameters of a procedure. This is something that I discovered when I created my REST service. I tested it by POSTing a payload with and without the {"request": .. } tags.
The payload without the tag failed to map the objects.
The payload with the tag mapped the objects to the input parameters and my procedure was able to read the value.
So back to my original question, can the REST service 'Insert' the {"request": .. } to an incomming POST?
Thanks, Tony.
I could not find any reference on the web that states the JSON payload for a REST service POST must have the opening {"request": .. } tag.
I'm thinking this is an OE requirement when you want to map objects in the payload to input parameters of a procedure. This is something that I discovered when I created my REST service. I tested it by POSTing a payload with and without the {"request": .. } tags.
The payload without the tag failed to map the objects.
The payload with the tag mapped the objects to the input parameters and my procedure was able to read the value.
So back to my original question, can the REST service 'Insert' the {"request": .. } to an incomming POST?
Thanks, Tony.
Flag this post as spam/abuse.
To add a bit of additional information: the {"request":...}, {"response":...}, and {"error":...} JSON payloads are proprietary formats implemented by OpenEdge to enable tunneling RPC like request parameters to an AppServer. They are the primary payload formats used by the OpenEdge Mobile JSDO support.
However, a developer does not have to use those formats at all if you are creating your own custom REST service to service any type of http client. The OpenEdge REST adapter [service] allows you the option of not using the restrictive REST mapping found in Mobile services, and to manually map different types of ABL data types to a http body (plus a lot more) in a wider variety of AppServer procedures and classes.
The choice is up to the developer, but the manual do-anything-for-anybody approach is much more work than what the Mobile JSDO requires for doing simple CRUD and invoke operations.
Hi Michael,
Thanks for the clarification. That was the info I was after.
I have experience with the Sonic workbench, so I was trying to find the equivalent method in the REST resource editor of developer studio.
This is where I'm at. As per the screen shot, I am not able to change the Expression value which always prefixes the 'request' tag.
With the sonic workbench I had to add a parameter to a properties file that allowed me to make those changes.
