How to send metadata when using restful api to upload a image?

[smoothdvd]

curl -X POST
-H "X-Parse-Application-Id: foo"
-H "X-Parse-REST-API-Key: bar"
-H "Content-Type: application/json"
--data-binary '@src/assets/test.png'
http://localhost:1337/parse/files/test.png

How to send metadata with this post request?

Like in JS SDK, we can do this by

const file = new Parse.File('myfile.zzz', fileData, 'image/png', metadata, tags);

[mtrezza]

You would set it in the Content-Type header.

See the examples in the docs where different content types are used, such as image/jpeg and text/plain.

[smoothdvd]

@mtrezza docs not mentioned how to send metadata or tags.

[mtrezza]

Did you try to set a request body like this:

fileData: {
    metadata: { ... },
    tags: { ... }
}

That is what happens in the Parse JS SDK.

[smoothdvd]

@mtrezza Yes, this is the "hack" way I used in my code.

curl -X POST
-H "Accept: application/json"
-H "Content-Type': text/plain"
-d '{"base64": "xyz", "fileData":{"metadata":{"foo":"bar"}, "tags":{}}, "_ContentType": "type", "_ApplicationId": "id", "_ClientVersion": "client"}

[mtrezza]

Glad to see it works. Adding fileData to the body is the correct way to do it, it is just not documented, well spotted!

Would you want to add this to the documentation and open a PR?

[smoothdvd]

@mtrezza Let me test it with move _ApplicationId from json body to header. And I also want upload file with multipart/form-data instead of base 64.

[mtrezza]

I'm closing this as it seems to be resolved. Feel free to comment if you have any questions and we can re-open this issue.

Docs issue in parse-community/docs#749

[evtimDev]

One important caveat for this working is one should not add the applicationId in the header, because otherwise the json parsing of the body will be skipped:

parse-server/src/middlewares.js

Lines 79 to 93 in fe02d3e

	if (!info.appId || !AppCache.get(info.appId)) {
	// See if we can find the app id on the body.
	if (req.body instanceof Buffer) {
	// The only chance to find the app id is if this is a file
	// upload that actually is a JSON body. So try to parse it.
	// https://github.com/parse-community/parse-server/issues/6589
	// It is also possible that the client is trying to upload a file but forgot
	// to provide x-parse-app-id in header and parse a binary file will fail
	try {
	req.body = JSON.parse(req.body);
	} catch (e) {
	return invalidRequest(req, res);
	}
	fileViaJSON = true;
	}

[mtrezza]

@evtimDev Do you think the documentation could be improved?

[evtimDev]

Hi @mtrezza! Yes, improved documentation for the REST API would be useful, I also noted it in the doc issue you created, just wanted to make sure it's captured and recorded.

I stumbled upon this issue as I wanted to send metadata & tags on file upload from the Android SDK (not supported there) so I had to roll-out a REST API solution for the Android. It is a useful feature, as it can simplify bookkeepings and also save on the additional request to associate a file with a object when the association is implemented in cloud code, on file after save, using the metadata/tags.

Since this is supported by JS SDK as well as the REST API, it makes sense to roll-out the capability to all platform SDKs.

In looking at the server code, it looks like this was some sort of special-case handling? I wonder if a more consistent approach would be for the server to receive the metadata and tags via headers instead - this will save trying to parse and validate the body as a json. I haven't looked at what changes would be needed on the client SDK side to support this in the iOS/Android SDKs.

Should I open new issues to investigate these? I'm thinking one issue per client SDK that does not support file upload with metadata/tags yet, plus one issue for server to support receiving these via headers, does that make sense?

[mtrezza]

It probably makes more sense to open a feature request in the specific SDK(s) where you have an actual need for your project. For the simple reason that there is currently low feature parity across SDKs - something we are currently looking into.
If you have a suggestion for what to add to the docs, please feel free to open a PR with a suggestion, since the issue already exists. We'll be happy to review.