Hey vikasloud
a 422 response indicates there's client error with the request content - obviously it depends on how your coders have implemented http handling but if they're following the standard HTTP RFC's for http response codes, you get a 400 for a malformed (syntactically incorrect) request and a 422 for invalid (schema invalid) requests.
So I'd double check the content of the request you are submitting to cause a 422 response.
However - you do mention that your request works with Postman, but doesn't with ReadyAPI so this gives us another avenue for analysis of your issue.
The first thing I do whenever I have this ReadyAPI! / Postman incongruency (i.e. it works in Postman, but not in ReadyAPI!) is to compare the HEADERS of the request and the response.
Essentially if the request works in Postman, but doesn't in ReadyAPI!, then I make changes to the ReadyAPI! request to match the Postman request. Most of the time when I've come across this Postman/ReadyAPI! inconsistency is to check the headers. More often than not - that's where the issue lies - fixing the cause of the header inconsistency fixes the overall problem.
If you screenshot the RAW request/response from Postman and ReadyAPI!, forum members will be able to provide more help.
Just need to emphasise - publishing this sort of stuff ISN'T a security concern as long as you do NOT provide the host associated with your request. Without the host/domain associated with your request, nefarious evil doers can't do anything. Naughty people cannot do anything if they haven't got the host/domain associated with your request - even if you publish every other detail (including all the config for authentication/authorisation).
If you do provide screenshots of the RAW request/response details of Postman/ReadyAPI! - remember the host/domain value is included - so just edit this out in the image and you'll be golden!
Cheers,
rich
Related Content
- 9 years ago
- 8 years ago