Question
SynTouch
NL
Last activity: 24 Jan 2021 19:25 EST
HTTP response from REST API
Hi all, I'm facing a strange situation using Pega API, that as not happening before.
I'm using Pega API to cretate test some business scenarios.
One of the scenarios should check if the response is like below... Validating if the property was not fulfilled...
{
"pxObjClass": "Pega-API-CaseManagement-Assignment",
"errors": [
{
"ID": "Pega_API_055",
"message": "Validation message found.",
"pxObjClass": "Pega-API-Error",
"ValidationMessages": [
{
"Path": ".ClientRequest.Content",
"pxObjClass": "Pega-API-Error-ValidationMessage",
"ValidationMessage": "This field may not be blank"
}
]
}
]
}
It was working fine.
But after some updates the response from the REST request I'm getting is an HTML similar that one...
<html><head> <title> Bad request </title> </head> <body> <p> We are sorry, but the request you have sent does not match the expected format. </ p > <p> If you think the request content is correct, please try again. </p> </body> </html>
When I check the log I see that message. That shows that the REST error code I was expecting is there.
API error for C204810: Pega_API_055: .ClientRequest.Content: This field may not be blank.
Looks like now, when something goes wrong (doesn't matter is its a real bad request or a validation) instead of replying as JSON, Pega is sending that generic HTML message.
Does anyone have any idea what may be going on? ***Edited by Moderator Kayla to update Platform Capability tags****
Pegasystems Inc.
AU
Hi Marco,
I've seen this occur when middleware between Pega and the service consumer detects the a HTTP response code that is not 200 and overrides the response body issued by Pega with its own HTML error page.
Is there a way you can send the same request directly to the Pega server - bypassing any reverse proxy servers or load balancers - and see whether Pega itself is continuing to send a JSON body for error scenarios? If you can prove that then your issue is somewhere between you and Pega, and not Pega itself.
Updated: 26 Nov 2020 5:20 EST
SynTouch
NL
Hi Braan, Thank you for your reply. I tried some scenarios using Postman. It doesn't seems to be the problem. Because when I tried run the same request with a opened case, I got the below response in JSON format for a 423 response code. Code: 423 Locked (WebDAV)
{
"pxObjClass": "Pega-API-CaseManagement-Assignment",
"errors": [
{
"ID": "Pega_API_031",
"message": "The resource that is being accessed is locked.",
"pxObjClass": "Pega-API-Error"
}
]
}
But what is interesting... When I change the request message with a non existent case ID the status code is 404, as expected, but the response message is also a HTML instead of JSON.
<html><head> <title> Not found </title> </head> <body> <p> It seems the site you are trying to access does not exist. Could you check the URL? </p> <p> If it turns out to be correct then the request is to make another attempt. </p> </body> </html>
For some status the response is JSON, for others is an HTML. Have you seen anything like this before? Regards, Marco.
Pegasystems Inc.
AU
Sorry I didn't get a notification about your post and am catching up on open questions.
Did you make any progress on this? I suspect it is a case of the middleware being more specific than when I suggested "a code that is not 200". Web servers often define error pages on a code-by-code basis, for the common HTTP error codes. Your initial post would have been a "400 Bad Request", returning HTML as did the "404 Not Found" that you posted later.
So I still think it is something in between Pega and you detecting 'common' errors and choosing to override the response sent from Pega with its own pre-defined error page for that particular error.