[OSM-dev] Structured error messages from API

Karl Guggisberg karl.guggisberg at guggis.ch
Thu Dec 10 17:18:07 GMT 2009

For JOSM, the structured data currently "embedded" in the error message is
important. Examples are object ids of already deleted objects (410 Gone) or
a date (the close date of a changeset in a 409 Conflict).

I'd prefer a parseable error document in case of http error codes,
preferably in XML. This would not be much of a change because the content of
the 'Error' http header is already replied as error document too (sometimes
for some error cases). 

It would be nice if the OSM API replied a message in english *and* and in
the language supplied in the "Accept-Language" http header. 

  <error-id code="1232" /> <!-- unique error code? would be nice too -->
  <message lang="en">Upload of an object failed.</message>
  <message lang="de">Hochladen eines Objekts ist fehlgeschlagen.</message>
  <property name="object-id" value="1223"/>
  <property name="closed-date" value="...."/>


-----Ursprüngliche Nachricht-----
Von: dev-bounces at openstreetmap.org [mailto:dev-bounces at openstreetmap.org] Im
Auftrag von Matthias Julius
Gesendet: Donnerstag, 10. Dezember 2009 17:16
An: dev at openstreetmap.org
Betreff: [OSM-dev] Structured error messages from API

There are requests in JOSM's trac to improve the handling of API errors.  To
do that JOSM needs to get a better understanding on what is wrong with the

Currently, JOSM is parsing the error strings the API is returning.
This is far from ideal because they are not structured, not documented and
might change without warning.

To improve things I would like to see the API extended to return meta data
about errors (error type, id of offending element, ...) in a structured way.
There are a couple of ways to that (that came to my mind):

- change the Error header
- add home-made HTTP headers (X-Error-Type ...)
- add pseudo headers to the body
- return a XML document containing all the info

(see also http://trac.openstreetmap.org/ticket/2544)

What do you think?

How important is that to people on the receiving end (application

Any suggestions how the format should be?


dev mailing list
dev at openstreetmap.org

More information about the dev mailing list