Hey guys, I was looking into AGPUSH-720 and I got an perception that not all error response do we actually know on the client-side. We should establish a common pattern - contract between server and client - which says how is a failure message transported from server to client, e.g.: - response header - response message body /w given structure

Right now, I've opened a PR for a generic failure handling mechanism that can catch and report any error: https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files

I plan to extend this error handling code dynamically as needed based on response codes (e.g. 404=Request resource is missing) and contract mentioned above ^. Wdyt? ~ Lukas

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Generally status code (e.g. 500) and status text (Server Response Failed) are not enough to provide meaningful feedback to the user. Sometimes we can use knowledge about the domain problem (e.g. GET /variants -> 404 = variant is missing), but often the client can't have any clue why server failed. It's important to pass this information to the user so he can act upon it. This will also help us to make our UPS code more robust, because error reports from UPS Admin Console will contain more information. ~~~ Usually REST interfaces follow common (API-wide) pattern (contract) that provides user with a meaningful message in a unified way. Disclaimer: btw it is possible we already use some pattern that I could miss. :-) ~~~ For example there is nice summary: https://blog.apigee.com/detail/restful_api_design_what_about_errors On Wed, Jun 18, 2014 at 6:38 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Sorry for the late response Lukas. > > On 2014-06-16, Lukáš Fryč wrote: > > Hey guys, > > > > I was looking into AGPUSH-720 and I got an perception that not all error > > response do we actually know on the client-side. > > > > We should establish a common pattern - contract between server and > client - > > which says how is a failure message transported from server to client, > e.g.: > > > > - response header > > - response message body /w given structure > > Speaking about a contract between client/server what would you suggest? > Maybe we can start a gist for these definitions once it affects other > clients? > > > > > > > Right now, I've opened a PR for a generic failure handling mechanism > that > > can catch and report any error: > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/226/files > > I've already commented on that, overall looks good. > > > > > I plan to extend this error handling code dynamically as needed based on > > response codes (e.g. 404=Request resource is missing) and contract > > mentioned above ^. > > > > Wdyt? > > > > > > ~ Lukas > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev