Tips or suggestions for uploading images?

AusMarkB

I need the ability to upload images and/or files of any kind.

I was working on the premise that the file/s would be sent as a base64 encoded string within a json object or array.
It's a little difficult for me to test so does anyone know if this approach would/should work?

In the meantime for some simpler testing, I've been through the uploading files via OECGI3 documentation but couldn't get anything to upload except a text file using mode 3 however mode 3 doesn't support binary files so that is not overly helpful.

Configuring the registry for modes 1 and 2 and nothing ever appears in the filepath directory.

So first question is has anyone tried and succeeded with encoding an image within a json string?
If it's not possible, what other limitations do I need to be aware of regarding uploading of files?

DonBakke

Hi Mark,

First I'll answer your technical question. Yes, you can can encode an image as Base64 and place it within a JSON string. Base64 is designed to be safe, so it's safe to embed in just about anything. JSON will just view it as string data.

However, I don't think that is the best way to do this. HTTP wants your requests to have uniform content type. That's why there's a Content-Type header. By wrapping Base64 data (Content-Type=text/plain) within a JSON array (Content-Type=application/json), you have mixed types being sent and the body is not self-descriptive. If you did this, it would be better to include an associated JSON name/value that identifies the content type.

We have two applications that upload images captured via device cameras (or the local photo gallery). We have opted to upload the images, encoded as Base64, separate from any associated text data (i.e., the "record"). This allows us to keep our content type well defined in the request header and our REST API relies upon standard HTTP rather than 1.) assuming the data is always a certain content type, or 2.) using a proprietary content type as I proposed above.

AusMarkB

I hear you about the content-type and I've managed to maintain that mindset when downloading images.
With uploading I have two scenarios.
1. Upload a file at a time to associate with a known existing record. Could be any type, image, pdf etc. and the name of the file is important.
2. Upload potentially multiple files (most likely images) as part of creating a new record.

In the simplest version where I need to associate files to an existing record, I was thinking this:

{
"docname": "someidentifier.ext",
"file":"ThisIsMyBase64data"
}

In the other scenario I was going with an object of text fields and an array of fields essentially the same as scenario 1. Kind of like this:

"incidentDt": "2016-06-16 13:42:22",
"site": "House at Stewart Rd",
"employeeName": "John Smith",
"details": "something happened and the glass shattered",
"incidentType": "Incident"
"files": [
{
"docname": "someidentifier.ext",
"file": "ThisIsMyBase64data"
},
{
"docname": "someOtherIdentifier.ext"
"file":"ThisIsMyBase64data"
}
]

I think what I read/hear you saying is that this could work though not strictly standard?

DonBakke

Mark,

To answer your question, "yes, it could work but it is not strictly standard". May I ask why the second scenario is required? Why could you not submit multiple requests? Keep in mind this will also benefit you in three ways:

1. Less overhead in a single request.
2. Better ability to track progress (i.e., you could display a progress indicator based on the number or requests that were sent).
3. Since JavaScript can be called asynchronously, you could potentially improve performance by having multiple requests being sent at the same time. Assuming you have enough engines available, each one can respond to each request simultaneously.

BTW, you don't need "docname" in your JSON. You could put this in your URL. The Base64 header contains the extension. So, you can reconstruct the filename if that was your intent.

AusMarkB

All valid points worth considering and of course I'll probably take them all on board.

For clarification the second scenario is not directly related to the first, just both involve uploading files.
The record being created in the second is not one that remote users will ever retrieve so at the moment to subsequently attach the files was not practical because there was no known relationship to the record created.

I'll probably change that now. :)