Good day all (again),
I'm not sure if this is a bug, or an issue on my side - I have (In trying to be complete) two versions of a PUT update
/manifests/someManifests/ (update based on dataset in body)
/manifests/someManifests/{manifestobj} (update by resource and dateset in body)
With the exception of the manifestobj input mapping, both methods (doPUT and doSinglePut, accept a longchar for the dataset to post [in part due to scientific notation issues], and output a dataset containing errors). Both are integer returns which map to the relevant HTTP responses [200,400 etc].
Issue 1. doPUT that is NOT doing url path mapping works 100%, doSinglePut that is doing url path mapping does NOT receiver the longchar from the adapter. Turning requestdumping on and adapter logging to 4 - shows that both REST methods receive the exact same BODY portion. However, the rest adapter log shows that when using the path mapping, the body seems to be ignored. I have deleted the mapping, and redone it, deleted the entire resource from the adapter and recreated it - it keeps on failing.
Issue 2 (possibly my error). So the longchar is read into a dataset - READ-JSON("LONGCHAR",myDataset,"EMPTY").
- Most of the time I get an error 400 correctly back saying that there is nothing to put. (I've also added an empty temp-table before the read-json). I can sometimes wind up getting a 200 error back, or a 400 saying e.g. the date is in the past even though its not even close to what i've posted.
So, the question at the end of the day is 1) can you have a BODY with a PUT that uses resource mapping of the path to input AND a body. 2) Is it that the base path is the same the issue ? :(
Oh dear,
I suspect that this is another bug. If I map the 4gl entry point to the body node and not a body parameter in the REST Resource URI editor it will work.
i.e. instead of sending {"request":"stuff":{....}} etc which I now just send it as
{"stuff":{....}} - and handle the body content myself. i.e. I link the parameter to the "body" node and not the sub node on the request side. Only problem is due to the api that was designed I'll have to accept {"request:} and change my API clean up to strup the request portion as needed.
Anyone else agree that if the body of a put / put (with resource encoded in url) has {"request":... that it both scenarios should map correctly without hackery ?
Hi -
It is possible to map HTTP request BODY to an Input parameter.
You may have multiple input parameters in your ABL program and you may want to receive their values from HTTP Request Body. In that case you map each input paramter to a sub-node in the "body". So in that case your Request payload will need to be wrapped in "request" node e.g.:
{ "request : { "p1" : {...} , "p2" : {...} , ...}
However, if there is just one input parameter you can directly map it to request body and you need not wrap it in request node. So you payload will simply be (as you mention):
{ "stuff" : {...} }
It is also possible to map the HTTP path parameter to the ABL input parameter.
So, if I understand your following question correctly:
1) can you have a BODY with a PUT that uses resource mapping of the path to input AND a body.
Answer) Yes
2) Is it that the base path is the same the issue ?
Answer) If you want to use Path parameter and body from the same REST request, you must use the Base URL with Path parameter in the URI space i.e:
taking your example:
VERB: PUT
URL : /manifests/someManifests/{manifestobj}
Path parameter {manifestobj} can be mapped to an ABL INPUT parameter
Request Body can mapped to another ABL parameter (NOTE: the JSON payload will need to be wrapped inside "request" node depending on how you map on input side - directly to body or to the sub-node)
I am sorry if I didn't answer the question that you asked. Please let me know if you have further question.