You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Andrei Shakirin <as...@talend.com> on 2012/12/13 13:42:19 UTC
Exception propagation in Rest interface: HTTP header vs body for
details
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?
Regards,
Andrei.
RE: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Jan Bernhardt <jb...@talend.com>.
+1 for ExceptionType in Response Header and FullExceptionDetails in Body
Regards.
Jan
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@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.
> >
RE: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Andrei Shakirin <as...@talend.com>.
> I don't understand why WorkflowException should be mapped to
> INTERNAL_SERVER_ERROR: you get workflow exceptions when something is
> not allowed within the current workflow instance, for example. There is no
> error on the server, the error is on the client asking for a workflow action not
> available for various reasons.
As far as I see, WorkflowException also wraps ActivitiException thrown by runtimeService, that can indicate problems with Activiti engine.
Anyway I do not have strong opinion regarding WorkflowException, if you think it is mostly causes by wrong client argument, let set it back to BAD_REQUEST.
> Similarly for PersistenceException - thrown for example when a duplicate key
> is found: this is not happening (under normal conditions) for a server fault
> but for a client's.
Normally, in case of duplicate keys DataIntegrityViolationException is thrown (mapped to HTTP.CONFLICT).
org.apache.ibatis.exceptions.PersistenceException can indicate following:
- error building SqlSession;
- error parsing SQL Mapper Configuration;
- cache problem;
- session problem;
- transaction exception
IMO it mostly caused by server errors as by wrong client request - not absolutely sure.
Regards,
Andrei.
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Sent: Freitag, 18. Januar 2013 15:20
> To: dev@syncope.apache.org
> Subject: Re: Exception propagation in Rest interface: HTTP header vs body
> for details
>
> On 18/01/2013 15:04, Andrei Shakirin wrote:
> > 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")
>
> I don't understand why WorkflowException should be mapped to
> INTERNAL_SERVER_ERROR: you get workflow exceptions when something is
> not allowed within the current workflow instance, for example. There is no
> error on the server, the error is on the client asking for a workflow action not
> available for various reasons.
>
>
> Similarly for PersistenceException - thrown for example when a duplicate key
> is found: this is not happening (under normal conditions) for a server fault
> but for a client's.
>
> > 2) Update some checked exceptions to runtime ones (see "Checked vs
> > Runtime exceptions")
>
> Sounds reasonable.
>
> Regards.
>
> >> -----Original Message-----
> >> From: Andrei Shakirin [mailto:ashakirin@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:ashakirin@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:sberyozkin@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.
> >>>>>
>
>
> --
> Dott. Francesco Chicchiriccò
> Tel +393290573276
>
> Amministratore unico @ Tirasa S.r.l.
> Viale D'Annunzio 267 - 65127 Pescara
> Tel +39 0859116307 / FAX +39 0859111173
> http://www.tirasa.net
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
> "To Iterate is Human, to Recurse, Divine"
> (James O. Coplien, Bell Labs)
>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Re: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 18/01/2013 15:04, Andrei Shakirin wrote:
> 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")
I don't understand why WorkflowException should be mapped to
INTERNAL_SERVER_ERROR: you get workflow exceptions when something is not
allowed within the current workflow instance, for example. There is no
error on the server, the error is on the client asking for a workflow
action not available for various reasons.
Similarly for PersistenceException - thrown for example when a duplicate
key is found: this is not happening (under normal conditions) for a
server fault but for a client's.
> 2) Update some checked exceptions to runtime ones (see "Checked vs Runtime exceptions")
Sounds reasonable.
Regards.
>> -----Original Message-----
>> From: Andrei Shakirin [mailto:ashakirin@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:ashakirin@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:sberyozkin@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.
>>>>>
--
Dott. Francesco Chicchiriccò
Tel +393290573276
Amministratore unico @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
"To Iterate is Human, to Recurse, Divine"
(James O. Coplien, Bell Labs)
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Andrei Shakirin <as...@talend.com>.
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:ashakirin@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:ashakirin@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:sberyozkin@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.
> > > >
RE: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Andrei Shakirin <as...@talend.com>.
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:ashakirin@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:sberyozkin@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.
> > >
RE: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Andrei Shakirin <as...@talend.com>.
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:sberyozkin@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.
> >
Re: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>
Re: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Exception propagation in Rest interface: HTTP header vs body
for details
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>