You might want to take a look at RFC2616, sec. 8.2.3:

—8<— snip —8<—

8.2.3 Use of the 100 (Continue) Status

The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.

—>8— snap —>8—

As you can see, this is not really your use case. Of course you could bend HTTP into whatever direction to make that stunt, but I would still recommend against it.

-A.

-- 
adesso mobile solutions GmbH
Dr. Alexander Papaspyrou
Chief Architect

Freie-Vogel-Str. 391 | 44269 Dortmund
T +49 231 930 66480 | F +49 231 930 9317 | M +49 172  209 4739

 

Vertretungsberechtigte Geschäftsführer: Dr. Josef Brewing, Frank Dobelmann
Registergericht: Amtsgericht Dortmund
Registernummer: HRB 13763
Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE201541832

Am 02.09.2014 um 15:41 schrieb Augusto Ciuffoletti <augusto@di.unipi.it>:

Why not a 1xx? SIP-like (ringing...)


2014-09-02 14:29 GMT+02:00 Papaspyrou, Alexander <papaspyrou@adesso-mobile.de>:
Hi Boris,

comments below.

Cheers,
Alexander

-- 
adesso mobile solutions GmbH
Dr. Alexander Papaspyrou
Chief Architect

Freie-Vogel-Str. 391 | 44269 Dortmund

 

Vertretungsberechtigte Geschäftsführer: Dr. Josef Brewing, Frank Dobelmann
Registergericht: Amtsgericht Dortmund
Registernummer: HRB 13763
Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE201541832

Am 02.09.2014 um 14:02 schrieb Boris Parak <xparak@mail.muni.cz>:

What I'm asking is:
Is it semantically acceptable to respond HTTP 200 OK and not HTTP
202 Accepted when the action hasn't been completed yet? How do we handle
failures after the HTTP 200 OK response has been sent to the client?

No, that would not be acceptable. If you get back a 200 OK for a manipulating operation, the operation should have completed. This is especially true for actions. The corner case here is that you have a long-running operation in the backend (stating 202 Accepted), which fails later; this is not handled by either OCCI or HTTP in a canonical way.

If this would affect a resource, I would expect the backend to send back the previous (unmanipulated) state of the resource on the next GET operation, or (if a new resource was supposed to created) a 404 Not Found, because it was never created in the first place.

An out-of-band status message whether (and what) failure has happened during the course of a 202 Accepted (until the operation has finished) is not something RESTful services handle nicely; usually, an operational status resource is created (which you can then poll), or a separate side channel (e.g. via Websockets) would be established.


_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg




--
Augusto Ciuffoletti
Dipartimento di Informatica
Università di Pisa
56100 - Pisa (Italy)