Maybe this is a difficult question to answer.

An HTTP 202 response will be returned for a request that has been
determined as a oneway service call. If something goes wrong before
that happens, there will be some HTTP 4xx/5xx error. The semantics of
HTTP 202 may differ depending on what your code (not the service code
itself but the extension/feature used with the service) is doing up to
that point.


2014-08-14 13:12 GMT+02:00 Iván Brencsics <[email protected]>:
> Hi,
>
> I had a general question about web services. Sorry, it is not related to
> CXF, but this is a so good community, maybe someone can help me:).
>
> In case of an async web service call the receiver acknowledges the request
> with an HTTP 202 usually. What is the semantics of this acknowledge:
>
> 1) We received the message, will process it later, and if no critical
> failure happens, will send back an async response. The message might get
> lost.

this is the case assumed for plain web services.

>
> 2) We received the message, validated it, so we can process it later. Will
> send back an async response later if no critical failures. The message
> might get lost.

if you add your validation interceptor before the above oneway switch
is taking place, you can get this behavior.

>
> 3) We received, validated and persisted the request. So it wont be lost. We
> will process it, and send back an async response later for sure.
>

similarly, if you have your custom persistence before the oneway
switch, you can also get this behavior. Another way of persisting the
request is using WS-RM. But with WS-RM, the HTTP code itself has not
much meaning as an Ack, as WS-RM uses its own SOAP based Ack messages
that are either returned in the HTTP response or sent back separately
using a separate connection to the client.

> 4) ...
>
> Does HTTP 202 has such a semantics, or does it leave the meaning open? Or
> if a system uses async calls, should it decide on its own, what does
> "acknowledge" mean?
>
> Regards,
> Ivan

Reply via email to