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