We're trying to use this library to interact with the vendor's API for retrieving Contracts from the vendor's DSTU2 endpoint. In particular, we are using the Contract.where() method to search for Contracts for a particular Patient.
I'm dealing with what seems to be incorrect responses being returned from the vendor's API for the Contract resource. In particular, the subType key in the response seems to be getting returned as subtype by the vendor's API. This predictably leads to a message like Superfluous entry "subtype" in data for <Contract object>, because presumably this library thinks that there is an extra unnecessary subtype key that should not be there, instead of subType as expected by the library/specification.
Questions
Is there a good way to deal with improperly named fields in the response in this way, as provided by the library? Like if there was some way to configure the Contract resource to expect subtype instead of subType?
If this isn't currently available by the library, is there a good workaround/hook/modification that I could do to modify the Contract resource and/or Client response to deal with this incorrectly labeled response key?
Summary
We're trying to use this library to interact with the vendor's API for retrieving Contracts from the vendor's DSTU2 endpoint. In particular, we are using the
Contract.where()method to search for Contracts for a particular Patient.I'm dealing with what seems to be incorrect responses being returned from the vendor's API for the Contract resource. In particular, the
subTypekey in the response seems to be getting returned assubtypeby the vendor's API. This predictably leads to a message likeSuperfluous entry "subtype" in data for <Contract object>, because presumably this library thinks that there is an extra unnecessarysubtypekey that should not be there, instead ofsubTypeas expected by the library/specification.Questions
subtypeinstead ofsubType?