If you don't mind doing assertions through code, you could use JsonSlurper to take the response string and make it into an object like:
import groovy.json.JsonSlurper String responseStr = "" // wherever you get the response from def response = new JsonSlurper().parseText(responseStr)
// Perform assertions here (just making this stuff up)
assert response.employees[0].id == 12345
response.employees.each {
assert it.salary > 0
}
Provided you're not trying to assert on some crazy complex stuff, this could work.
JustinM89 - cheers fella - I'll check this out
nmrao - it's a defect from the perspective that the type specified doesn't reflect the payload content - but this doesn't change the payload content itself - so the API 'works successfully'. The requirements for this API only specifies the headers on the request - not the response. Furthermore - Its a well known 3rd party in use by lots of companies - the impact of changing the 'type' to what it should be won't make any difference to the API itself from a functional perspective - it will just make testing easier.
Hence the reason there's no point raising it with the 3rd party. The API successfully responds with a .json fragment - its just hte Content-Type header that is 'incorrect'. Lots of other companies use this and haven't raised it as a ticket because excepting impacting performance sending as text/plain rather than application/json wont make any difference - or these other companies haven't noticed the issue - as I say - there's no functional impact - only a slight performance one.
Cheers,
rich
