[Grub-dev] Server answer codes

[Balinny]

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.