I have tried to summarize remote exceptions mapping as well as some improvement 
ideas in [1].
[1] is also linked from [2].
Review, remarks, discussions are welcome.

Cheers,
Andrei.

[1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade


> -----Original Message-----
> From: Andrei Shakirin [mailto:ashaki...@talend.com]
> Sent: Freitag, 14. Dezember 2012 09:37
> To: dev@syncope.apache.org
> Subject: RE: Exception propagation in Rest interface: HTTP header vs body for
> details
> 
> Yep, will go this way: keep current propagation one to one plus more
> verbose exception in HTTP body (perhaps on the second step).
> Thanks for participating in discussion.
> 
> Cheers,
> Andrei.
> 
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
> > Sent: Donnerstag, 13. Dezember 2012 18:34
> > To: dev@syncope.apache.org
> > Subject: Re: Exception propagation in Rest interface: HTTP header vs
> > body for details
> >
> > On 13/12/12 16:45, Francesco Chicchiriccò wrote:
> > > On 13/12/2012 14:27, Sergey Beryozkin wrote:
> > >> Hi
> > >> On 13/12/12 12:42, Andrei Shakirin wrote:
> > >>> Hi,
> > >>>
> > >>> I am working on Rest interface migration (to Apache CXF) and
> > >>> analysing exception propagation from service to client.
> > >>> Actually SyncopeClientCompositeErrorException is sent using:
> > >>>
> > >>> a) ExceptionType HTTP header containing exception type
> > >>> (enumeration
> > >>> SyncopeClientExceptionType)
> > >>>
> > >>> b)<ExceptionType>.element HTTP header as list of strings for error
> > >>> details (that are used to fill SyncopeClientException.elements)
> > >>>
> > >>> I find that fine at the moment, as far as details information is
> > >>> only simple and short list of strings. Potentially it is possible
> > >>> to have more complex and long structures in exception details.
> > >>> Therefore the question is does it make sense to use HTTP header
> > >>> only for ExceptionType and send details in HTTP body?
> > >>> It means that we will change network protocol between client and
> > >>> service, not sure how critical it is for existing Syncope users.
> > >>>
> > >>> There are 2 alternatives:
> > >>>
> > >>> a) leave the propagation as it is: send type and details in HTTP
> > >>> headers. In the future additional information exceptional still
> > >>> can be sent with HTTP body.
> > >>>
> > >>> b) send only ExceptionType in HTTP header and details element in
> > >>> HTTP body.
> > >>>
> > >>> Do you have any preferences for (a) and (b) or there are other
> > >>> alternatives?
> > >>
> > >> Perhaps it might make sense to keep a simple HTTP header anyway,
> > >> for the receivers to be optionally able to quickly check the
> > >> exception type without having to read the response, and also return
> > >> the body with all the details, including the actual exception type,
> > >> so that the whole info can then be analyzed on the client side
> > >> after the request has been completed, so one more possible option
> > >> :-)
> > >
> > > Hi,
> > > I like this (c) option as well:
> > > 1. ExceptionType + elements in the HTTP header (like as now) 2. HTML
> > > (short) body with more verbose description, possibly localized
> > >
> > > (1) could be used by 3rd party REST clients while (2) could be used
> > > to provide better error message for admin console.
> > >
> >
> > Hi, I'm rereading and I guess I may've repeated what Andrei already
> > suggested with his option a) :-)
> >
> > Either way, looks like we all in agreement
> >
> > Cheers, Sergey
> >
> > > Regards.
> > >

Reply via email to