[openstreetmap/openstreetmap-website] API /gpx/#id/data documentation and behaviour (Issue #3487)

[Simon Poole]

### Description

I'm in the process of refactoring the GPX support in Vespucci see https://github.com/MarcusWolschon/osmeditor4android/projects/1#column-15955445 and one of the potential enhancements is downloading tracks for the user (logged in, as there is no reasonable way to retrieve public traces currently via the API). 

The /gpx/#id/data API call is documented here https://wiki.openstreetmap.org/wiki/API_v0.6#Download_Data:_GET_.2Fapi.2F0.6.2Fgpx.2F.23id.2Fdata If the behaviour was as described, this would be fairly painful as it would require handling a (undocumented) multitude of archive formats. However inspection of the code https://github.com/openstreetmap/openstreetmap-website/blob/master/app/controllers/api/traces_controller.rb#L53 shows that the returned format can actually be forced to GPX (and XML, however that is supposed to be useful in this context).

This is insofar helpful as it makes things easy on the client side. There is however a lingering question wrt multi file archives, experimentation shows that the contained files are simply concated together in the output, a slightly original solution (https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2 would likely be 'correct'), but completely parseable ignoring nitpicking. 

The question is if this is intended behaviour that will be maintained going forward and can be documented, or if this is simply an unintended implementation consequence that cannot be relied on?

### Screenshots

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/3487
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/3487 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20220303/0aac8d79/attachment.htm>