You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Chamila De Alwis <ch...@wso2.com> on 2015/04/13 20:55:09 UTC
[Discuss] Error handling in the REST API
Hi,
Is there a specific reason for throwing exceptions in the REST API without
handling them and returning suitable response codes? This is observed in
several methods where either the util methods throw exceptions that are not
handled in the API method, or the API method directly throws exceptions.
IMO most of these scenarios have to be handled by returning a status code
and not producing a stack trace.
For example removeDeploymentPolicy method
("/deploymentPolicies/{depolymentPolicyID}") will throw an exception and
produce a stack trace when the specified deployment policy ID is not found.
Ideally this method should handle the exception and return a 404, since it
is not a deal breaking scenario and should not produce noise on the log.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
Re: [Discuss] Error handling in the REST API
Posted by Chamila De Alwis <ch...@wso2.com>.
Hi Imesh,
On Tue, Apr 14, 2015 at 11:44 PM, Imesh Gunaratne <im...@apache.org> wrote:
> IMO the UI should be able to read HTTP status code. If we are including
> another status/error code attribute, it may needs to include a set of
> Stratos specific status/error codes.
>
Agreed. The CLI is another code segment which needs to improve how it reads
the REST API response. Currently in most commands, it doesn't check the
status code to output success or failure of the command.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
Re: [Discuss] Error handling in the REST API
Posted by Imesh Gunaratne <im...@apache.org>.
IMO the UI should be able to read HTTP status code. If we are including
another status/error code attribute, it may needs to include a set of
Stratos specific status/error codes.
On Tue, Apr 14, 2015 at 8:52 PM, Chamila De Alwis <ch...@wso2.com> wrote:
> Hi Imesh,
>
> The status code duplication seems to be to accommodate UI requirements.
> AFAIU the SuccessResponseBean and ErrorResponseBean are serialized in to
> JSON which is displayed in the UI message pop ups.
>
>
> Regards,
> Chamila de Alwis
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, Apr 14, 2015 at 11:06 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> Correct, the API should not raise exceptions as the client would not know
>> how to decode them. Yes, currently there is some space for improvements in
>> $subject.
>>
>> I also noted few problems in the error message format we have used
>> (duplicating HTTP status code, attribute name "successMessage", etc). We
>> need to fix this properly for the 4.1.0 GA.
>>
>> Thanks
>>
>> On Mon, Apr 13, 2015 at 10:32 PM, Chamila De Alwis <ch...@wso2.com>
>> wrote:
>>
>>> Looks like the status returned when an exception is thrown is 400 (bad
>>> request). This should vary depending on the type of exception thrown from
>>> the backend, probably among 404 and 500.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Tue, Apr 14, 2015 at 12:25 AM, Chamila De Alwis <ch...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is there a specific reason for throwing exceptions in the REST API
>>>> without handling them and returning suitable response codes? This is
>>>> observed in several methods where either the util methods throw exceptions
>>>> that are not handled in the API method, or the API method directly throws
>>>> exceptions. IMO most of these scenarios have to be handled by returning a
>>>> status code and not producing a stack trace.
>>>>
>>>> For example removeDeploymentPolicy method
>>>> ("/deploymentPolicies/{depolymentPolicyID}") will throw an exception and
>>>> produce a stack trace when the specified deployment policy ID is not found.
>>>> Ideally this method should handle the exception and return a 404, since it
>>>> is not a deal breaking scenario and should not produce noise on the log.
>>>>
>>>> Regards,
>>>> Chamila de Alwis
>>>> Software Engineer | WSO2 | +94772207163
>>>> Blog: code.chamiladealwis.com
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Error handling in the REST API
Posted by Chamila De Alwis <ch...@wso2.com>.
Hi Imesh,
The status code duplication seems to be to accommodate UI requirements.
AFAIU the SuccessResponseBean and ErrorResponseBean are serialized in to
JSON which is displayed in the UI message pop ups.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Tue, Apr 14, 2015 at 11:06 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Correct, the API should not raise exceptions as the client would not know
> how to decode them. Yes, currently there is some space for improvements in
> $subject.
>
> I also noted few problems in the error message format we have used
> (duplicating HTTP status code, attribute name "successMessage", etc). We
> need to fix this properly for the 4.1.0 GA.
>
> Thanks
>
> On Mon, Apr 13, 2015 at 10:32 PM, Chamila De Alwis <ch...@wso2.com>
> wrote:
>
>> Looks like the status returned when an exception is thrown is 400 (bad
>> request). This should vary depending on the type of exception thrown from
>> the backend, probably among 404 and 500.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, Apr 14, 2015 at 12:25 AM, Chamila De Alwis <ch...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Is there a specific reason for throwing exceptions in the REST API
>>> without handling them and returning suitable response codes? This is
>>> observed in several methods where either the util methods throw exceptions
>>> that are not handled in the API method, or the API method directly throws
>>> exceptions. IMO most of these scenarios have to be handled by returning a
>>> status code and not producing a stack trace.
>>>
>>> For example removeDeploymentPolicy method
>>> ("/deploymentPolicies/{depolymentPolicyID}") will throw an exception and
>>> produce a stack trace when the specified deployment policy ID is not found.
>>> Ideally this method should handle the exception and return a 404, since it
>>> is not a deal breaking scenario and should not produce noise on the log.
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
Re: [Discuss] Error handling in the REST API
Posted by Imesh Gunaratne <im...@apache.org>.
Correct, the API should not raise exceptions as the client would not know
how to decode them. Yes, currently there is some space for improvements in
$subject.
I also noted few problems in the error message format we have used
(duplicating HTTP status code, attribute name "successMessage", etc). We
need to fix this properly for the 4.1.0 GA.
Thanks
On Mon, Apr 13, 2015 at 10:32 PM, Chamila De Alwis <ch...@wso2.com>
wrote:
> Looks like the status returned when an exception is thrown is 400 (bad
> request). This should vary depending on the type of exception thrown from
> the backend, probably among 404 and 500.
>
>
> Regards,
> Chamila de Alwis
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, Apr 14, 2015 at 12:25 AM, Chamila De Alwis <ch...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Is there a specific reason for throwing exceptions in the REST API
>> without handling them and returning suitable response codes? This is
>> observed in several methods where either the util methods throw exceptions
>> that are not handled in the API method, or the API method directly throws
>> exceptions. IMO most of these scenarios have to be handled by returning a
>> status code and not producing a stack trace.
>>
>> For example removeDeploymentPolicy method
>> ("/deploymentPolicies/{depolymentPolicyID}") will throw an exception and
>> produce a stack trace when the specified deployment policy ID is not found.
>> Ideally this method should handle the exception and return a 404, since it
>> is not a deal breaking scenario and should not produce noise on the log.
>>
>> Regards,
>> Chamila de Alwis
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Error handling in the REST API
Posted by Chamila De Alwis <ch...@wso2.com>.
Looks like the status returned when an exception is thrown is 400 (bad
request). This should vary depending on the type of exception thrown from
the backend, probably among 404 and 500.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Tue, Apr 14, 2015 at 12:25 AM, Chamila De Alwis <ch...@wso2.com>
wrote:
> Hi,
>
> Is there a specific reason for throwing exceptions in the REST API without
> handling them and returning suitable response codes? This is observed in
> several methods where either the util methods throw exceptions that are not
> handled in the API method, or the API method directly throws exceptions.
> IMO most of these scenarios have to be handled by returning a status code
> and not producing a stack trace.
>
> For example removeDeploymentPolicy method
> ("/deploymentPolicies/{depolymentPolicyID}") will throw an exception and
> produce a stack trace when the specified deployment policy ID is not found.
> Ideally this method should handle the exception and return a 404, since it
> is not a deal breaking scenario and should not produce noise on the log.
>
> Regards,
> Chamila de Alwis
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>