(1) The error_params parameter now always holds an empty JSON array, mainly for compatibility reasons with clients expecting something here
(2) The error_desc field is newly introduced and contains a technical error message (always English), useful for debugging the problem or putting it into a client-side log
(3) If configured, the error_stack parameter provides the stack trace of the associated Java exception
A potential issue might arise if clients directly access the error_params array, since they can no longer rely on the presence of replacement parameters there, e.g. for the data size parameters ( http://oxpedia.org/wiki/index.php?title=HTTP_API#DataSizeParameters ). Therefore, client applications should check their compatibility with the new handling.
The complete format of the response body is documented at http://oxpedia.org/wiki/index.php?title=HTTP_API#Low_level_protocol .
(2) The error_desc field is newly introduced and contains a technical error message (always English), useful for debugging the problem or putting it into a client-side log
(3) If configured, the error_stack parameter provides the stack trace of the associated Java exception
A potential issue might arise if clients directly access the error_params array, since they can no longer rely on the presence of replacement parameters there, e.g. for the data size parameters ( http://oxpedia.org/wiki/index.php?title=HTTP_API#DataSizeParameters ). Therefore, client applications should check their compatibility with the new handling.
The complete format of the response body is documented at http://oxpedia.org/wiki/index.php?title=HTTP_API#Low_level_protocol .