[Grub-dev] Server answer codes

Yousef Ourabi yourabi at zero-analog.com
Tue Jan 29 20:51:52 UTC 2008


I understand the synchronous vs async nature of 201 vs 202, however I'm
still not convinced on 202 as the de-facto response code.

The question in my mind what does the client need to know about. On 201, the
newly created resource can/should be returned via the Location: header. This
is proper and on normal operation I believe this is what should be returned.

As Seth has pointed out, if hBase is currently down, degrading to a 202 is
also appropriate.

The distinction I want to make is that I don't think we should just blanket
responses with something "non-committal" when we are able to be more
specific.


-Yousef


On 1/29/08, Balinny <balinny at gmail.com> wrote:
>
> Yousef Ourabi wrote:
> > I'm going to continue raising a stink from this. IF we are going to do
> > a REST interface, we are going to do it the right way.  You'll note
> > the description of the 500 erros:
> > 5xx: Server Error - The server failed to fulfill an apparently valid
> request
> >
> Yes, but that would be an error of "Disk full", "Can't save file"...
> Which leaves the subsequent work to the client to retry later.
> 202 (Accepted) adequates perfectly:
>
> The request has been accepted for processing, but the processing has not
> been completed. The request might or might not eventually be acted upon,
> as it might be disallowed when processing actually takes place. There is
> no facility for re-sending a status code from an asynchronous operation
> such as this.
>
> The 202 response is intentionally non-committal. Its purpose is to allow
> a server to accept a request for some other process (perhaps a
> batch-oriented process that is only run once per day) without requiring
> that the user agent's connection to the server persist until the process
> is completed. The entity returned with this response SHOULD include an
> indication of the request's current status and either a pointer to a
> status monitor or some estimate of when the user can expect the request
> to be fulfilled.
>
>
> It's not a server error (5xx) as fas as Seth remembers to run the script
> and those files are finally loaded into hbase.
> _______________________________________________
> Grub-dev mailing list
> Grub-dev at wikia.com
> http://lists.wikia.com/mailman/listinfo/grub-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikia.com/pipermail/grub-dev/attachments/20080129/77ea8160/attachment-0001.html 


More information about the Grub-dev mailing list