Response Processing
Overview
Response processing is the final step in the request flow. The primary goal of this step is to filter inaccessible properties. These properties may be inaccessible due to resource object permissions or property access rules.
Where a property permission results in an ALLOW, the property will be included in the response. If the permission results in a DENY, the property will be omitted from the response.
By default, only READ or SEARCH operations result in a non-blank payload.
In HTTP, this results in a 200 response status if everything was successful. In the
case of CREATE, UPDATE and DELETE responses, the response normally
has no payload and in the case of an HTTP request, this results in a 204 response
status. It is possible to override this behaviour though and force Appirator
to respond with the full target resource object during response processing. This
means that if an HTTP PATCH update was used to update a resource object and this
option has been enabled, rather than just the updated properties being returned
the entire resource object is returned.
Whenever the response is not blank, the property authorisation described above is performed.
Once the object has been filtered, all remaining properties are serialised
as needed, for the response. If the request was an HTTP request, the response
is serialised according to the requested Accept header. Accepted values for
the Accept header are:
application/jsonapplication/xmltext/xml
If the request flow was initiated through a module or application script, where a payload is returned, the payload is an object compatible with the script language.