going from version 0 to version 1 was a major step for us and included major changes to the API. We changed the URL, because also the underlying API/processing underwent breaking changes.
The old URL is still there. The old API can still be used to get data that was uploaded before the change. Unfortunately, we had to discontinue the upload of new data and cannot provide any new data through the old API/URL.
I know that this can be annoying, but these major breaking updates should be infrequent. Of course, I cannot make any promises for the far future.
For the upload endpoint in particular the API has not change too much. Here are the docs of the new one. It is a post not, not a put; but most of the parameters stayed the same. The subsequent endpoints to change metadata and published have changed more significantly.
The JSON part is interesting (and quite astonishing as “all” responses are generated by a framework). I would really like to get to the bottom of this. Do you have an example output? What endpoint?
Ok another thing (unrelated): When I donwload raw data I get a file raw without file ending or anything. Then I have to guess it’s a zip file to be able to unpack it.
The problem is the “| xargs echo” at the end of one of the commands shown on the gui. I think we added it, to show the progress of the upload which is otherwise lost in the piping.
The problem is that xargs strips quotes from the input (in this case the curl output). If you omit the | xargs echo, you’ll get the right json (but no progress bar).
We should probably revise these offered command examples. The whole xargs thing is quite “hacky”.
I am clicking through our various download options. Downloading multiple files from the raw files tab of an individual entry only shows the entryid and not .zip. Here it would be better that raw.zip. We can change that.
The other downloads (download button on top of upload page, download entries from the processing step of the upload page, download button in the overall search), seem all to suggest raw.zip as download file name. Maybe it is my browser making assumptions based on the content type header.
If you use the API, we are a bit limited. Not really sure how curl would create a file name.
The raw problem seems to be happening in Firefox, not Chrome. We switched to a proper library to implement the downloads in an upcomming release (don’t worry the URLs wont change;-). This will fix this problem.