[occi-wg] Fwd: Feedback, suggestions and questions from EGI FedCloud

Augusto Ciuffoletti augusto at di.unipi.it
Tue Sep 2 09:41:23 EDT 2014


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


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

>  Hi Boris,
>
>  comments below.
>
>  Cheers,
> Alexander
>
>     --
> *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
> Mail: papaspyrou at adesso-mobile.de | Web: www.adesso-mobile.de |
> Mobil-Web: mobil.adesso-mobile.de
>
>
> 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 at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/occi-wg
>
>


-- 
Augusto Ciuffoletti
Dipartimento di Informatica
Università di Pisa
56100 - Pisa (Italy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140902/dd543f61/attachment.html>


More information about the occi-wg mailing list