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. > > >