+1 for ExceptionType in Response Header and FullExceptionDetails in Body Regards. Jan
> -----Original Message----- > From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] > Sent: Donnerstag, 13. Dezember 2012 14:28 > To: dev@syncope.apache.org > Subject: Re: Exception propagation in Rest interface: HTTP header vs body > for details > > 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 :-) > > > > Cheers, Sergey > > > > > Regards, > > Andrei. > >
