Hi Bill, I was facing a similar (but not identical) issue not too long ago where I was trying set %response.Status in my REST handler class, only to have a different status code reflected in the response to the client.
The issue ended up being that the request to the REST handler class that I was working on was being forwarded from another REST handler class that extends EnsLib.REST.Service rather than %CSP.REST. The EnsLib REST handler works a little differently. The user code is supposed to write the output to a response stream, with the response headers being set as attributes of the stream, rather than setting headers of %response directly.
So my question is, is your REST handler downstream from an EnsLib.REST.Service REST handler? I also see that your REST handler extends Ens.BusinessService. I wonder if something in that class is overriding your %response headers. Is there any way you can test your class with that superclass removed?
I'm not sure in what version %JSON.Adaptor was introduced, but if it's in your version, you can have the class modeling your object extend %JSON.Adaptor, which will give you access to the %JSONImport() method, which can de-serialize a JSON payload into an object.
One caveat to this is that I believe any serial objects referenced by the top-level object will also need to extend %JSON.Adaptor for the import to work properly.
Assuming that tSC is a %Library.Status, I don't think this will work the way you intend it to. The argument to a THROW has to be an oref to a class that extends %Exception.AbstractException:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_cthrowIf you have a %Status that you need to throw as an exception, you can use $$$ThrowOnError or $$$ThrowStatus, both defined in %occStatus.inc. They both call ##class(%Exception.StatusException).ThrowIfInterrupt(), but $$$ThrowOnError only does so if the status is an error, so it's slightly more efficient if you haven't checked the status yet.
Log in or create a new account to continue