[OSM-dev] Overpass-API error codes
ian.dees at gmail.com
Mon Apr 9 22:35:49 BST 2012
On Mon, Apr 9, 2012 at 4:29 PM, Roland Olbricht <roland.olbricht at gmx.de>wrote:
> Am Freitag, 30. März 2012 11:15:26 schrieb Peter Wendorff:
> > Hi.
> > In a software I'm going to use the Overpass-API to fetch OSM-Data, and I
> > think about handling error codes.
> > As far as I see, Overpass prints errors in a <remark>-Tag in human
> > readable text, but nowwhere as machine-readable text, while most error
> > codes I guess could be mapped on HTTP-response states.
> Well, I'm not sure whether HTTP-response codes are here the best way to
> error states. The by far most important error situations are
> 1. A timeout on the server
> The client shouldn't use the result, as it may be incomplete. It can
> with a longer timeout.
> 2. Connection refused
> This would happen in case of overload, does happen rarely at the moment,
> but it should be addressed by a client. The client should retry after a
> timespan of 1 to 5 seconds again.
> 3. A malformed request
> It would be unusual if this happens when the request is generated
> programmatically. If a human user has entered the query, the client
> pass the HTML document to the human user.
All of these have analogues in HTTP error codes. #1 and #2 should probably
be HTTP 5xx (because it's a server problem) and #3 should be an HTTP 4xx of
some sort (because the client did something wrong).
> The more simpler approach would be to process the result if it is OSM XML
> to pass it to the end user if it is HTML.
> Specifically the first one cannot be handled by a HTTP status code. The
> code is always the first thing to be written. Thus, to send a different
> status code in case of a timeout, the servers needs to held back the
> until the request has been completed. That impedes a couple of use cases
> the client could take advantage of early arriving responses. Thus, a
> started with HTTP 200 may still fail later with a timeout.
You shouldn't write your response out until it's ready. If you want to
return the HTTP header quickly then you should respond with a "polling URL"
that the client can check for the result when it's finished.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev