[OSM-dev] Overpass-API error codes

Ian Dees 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
> encode
> 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
> retry
>   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
> should
>   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
> and
> to pass it to the end user if it is HTML.
>
> Specifically the first one cannot be handled by a HTTP status code. The
> status
> code is always the first thing to be written. Thus, to send a different
> HTTP
> status code in case of a timeout, the servers needs to held back the
> payload
> until the request has been completed. That impedes a couple of use cases
> where
> the client could take advantage of early arriving responses. Thus, a
> response
> 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...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20120409/7a359fc0/attachment.html>


More information about the dev mailing list