Hi, >From proposals regarding remote exceptions in [1], I am going to do the >following during CXF migration: 1) Update HTTP mapping codes (see "Mapping exceptions to HTTP codes") 2) Update some checked exceptions to runtime ones (see "Checked vs Runtime exceptions")
WDYT? Cheers, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:ashaki...@talend.com] > Sent: Montag, 7. Januar 2013 10:01 > To: dev@syncope.apache.org > Subject: RE: Exception propagation in Rest interface: HTTP header vs body for > details > > 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. > > > >
