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 <[email protected]> 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 <[email protected]> > 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
