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