Don't B64 encode data in download.json?

[broofa]

Is there a reason the data field in download.json responses is base-64 encoded? It appears to decode to plain text (text/xml), so should be fine as a JSON string field. Looking at https://www.thrustcurve.org/api/v1/download.json?motorId=5f4294d20002310000000010 , FWIW.

[JohnCoker]

I wanted the option to include other formats. In particular, at times the test stand data (DAP files for TMT) have been available and I didn't want to preclude the ability to handle binary data.

[broofa]

Okay, that makes sense. Is the fact this is base64 encoded documented anywhere? I only figured it out because the data "looked" base64 encoded. Maybe consider renaming the field to base64Data in v2?

Related thought: As a consumer of this API, the fact this data is in a non-JSON format is a bit of an annoyance. I'm specifically requesting JSON data ("download.json"), but I'm stuck having to parse these esoteric 3rd-party formats. RASP, RockSim, DAP... whatever. It's a solvable problem, but every thrustcurve client is going to have to solve that same problem... which kind of argues that it'd be better to solve it once, at the source.

I.e. It'd be nice if the data were delivered as top-to-bottom, structured, JSON. And, yes, I know that's implicitly asking for yet-another motor format. I.e. I don't have a solution... 'just pissing into the wind as it were. "Thanks for listening", I guess. :-)

[JohnCoker]

The thrust/time points are extracted and made available separately. We can follow this pattern for other attributes if desirable.

I think the file data itself should be delivered unchanged, so that simulators and such can use it if they already understand it.

[broofa]

Sorry to dwell on this, but the more I think about this the worse this "smells". HTTP is purpose-built for transferring data files like this. Embedding the data inside JSON ignores all the goodness that comes from that - Content-Type headers, mime-types, eTags, caching headers, CDNs, Content-Disposition: attachment to force browsers to download instead of display a file - all that stuff.

In thinking about this further I'd suggest pulling the actual data portion of this endpoint out into it's own URL. One for the metadata (what's currently provided minus the file content), and one for the data file(s). For example...

** GET /motors/someMotorId** might return ...

{
  "motorId": "##someMotorId##",
  "datafiles": [
    {
      "format": "RockSim",
      "url": "/datafiles/someMotorId.rse",
      "source": "user",
      "infoUrl": "#####",
      "simfileId": "#####"
    },
    {
      "format": "RASP",
      "url": "/datafiles/someMotorId.eng",
      "source": "cert",
      "infoUrl": "#####",
      "simfileId": "#####"
    },
    "etc..."
  ]
}

Where the datafiles[#].url values all point to an endpoint of the general form...

/datafiles/:motorId.[rse|eng|dap] - raw file data (with content type and caching headers set appropriately and all that jazz)

This makes getting the actual file data a slightly more tedious but is logically much more in line with how the data is actually structured I believe.

Anyhow... food for thought.

[JohnCoker]

Sure, that makes sense. I have no objections to a major rework for the API v2. (The primary goal of v1 was to be backwards compatible with I started supporting in 2008.)