Re: ERRest - Proper handling of error conditions
Re: ERRest - Proper handling of error conditions
- Subject: Re: ERRest - Proper handling of error conditions
- From: Gino Pacitti <email@hidden>
- Date: Fri, 23 Dec 2016 16:27:18 -0400
something like this.. perhaps?
https://stripe.com/docs/api#errors
> On 23 Dec 2016, at 16:19, Altera WO Team <email@hidden> wrote:
>
> Ok, but what if I want to tell the user what's wrong?
> And I would love to handle the specific text of the message server side...
>
> For example now I send 409 (CONFLICT) if somebody tries to register with the same email as another already registered user.
> On the app I present a specific message for each 4XX error but I'd really like to handle the wording of those messages server side.
>
>
>
>> On 23 Dec 2016, at 21:13, Pascal Robert <email@hidden> wrote:
>>
>> It is a valid way. When the problem is the received data, the HTTP should be in the 4xx range. I would return a 400 (Bad Request) with the JSON in the body.
>> De : webobjects-dev-bounces+probert=email@hidden <webobjects-dev-bounces+probert=email@hidden> de la part de Altera WO Team <email@hidden>
>> Envoyé : 23 décembre 2016 07:13:45
>> À : WebObjects-Dev Mailing List List
>> Objet : ERRest - Proper handling of error conditions
>>
>> Hi List,
>>
>> I found myself a lot trying to elegantly handle EO creation errors when using ERRest as backend for (mostly) iOS applications using JSON.
>>
>> For example, imagine i have an entity called User and for the user the emailAddress field is unique in the DB, so I won't be able to create two User objects with the same emailAddress.
>>
>> I will have a UserController and inside that controller a createAction method... If I just put the simplest implementation possible like that:
>>
>> public WOActionResults createAction() {
>> User user = create(createFilter());
>> editingContext().saveChanges();
>> return response(user, showIDAndTokenFilter());
>> }
>>
>> In case of error the user will get a 500 response with Content-Type: application/json but the response body won't be JSON but plain text of the exception (exposing all the details of the SQL query which is of course a security issue). That is a problem for example in iOS in which i get a parsing error as the json can't be parsed.
>>
>> The way in which I usually approach the issue is of course to always put the saveChanges in a try-catch and then return errorResponse(ERXHttpStatusCodes.SOME_ERROR_CODE);
>> and I use specific error codes for each of the possible cases (missing fields, duplicate entries, etc). So basically I use 4xx errors for most of the cases I catch and then fallback to 500 when something else happens.
>>
>> I'm not sure this is the best approach as I'm pretty sure it's not standard so I'm asking for the wisdom of the community to try to come up with at least the ERRest standard.
>> I considered returning a proper JSON response with a status code of 500 and some error message in a JSON Object, would it make sense?
>>
>> Thanks,
>>
>>
>>
>> Matteo
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden