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. Example: <osm-api-error> <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="...."/> </osm-api-error> Regards Karl -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Matthias Julius Gesendet: Donnerstag, 10. Dezember 2009 17:16 An: [email protected] 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 data. 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 developers)? Any suggestions how the format should be? Matthias _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
