I have a question almost a month on the subject. At certain point in my application, the user can upload to a library of files.
This upload needs to be logged in a table named midias , where, in addition to the file path, I also need extra data such as name, description, file permission, plus metadata information such as file size and file extension .
The question that arises in this case is the following: For registration in the database for this file, I also need the other information. And, since the requests usually use the JSON content-type, I wonder how the file would be sent, since JSON has a certain limitation on the characters that can be included in it.
Hypothetical example:
POST /api/midias/
Content-Type: application/json
{
"nome" : "Flor",
"descricao" : "A flor azul encontrada na
"tipo_acesso" : 1,
"extensao" : "jpg",
"tamanho" : 5225,
"arquivo" : ???????
}
That is, according to the example above, for creating the resource in my API, in addition to the media information, I also needed to send the binary file, to upload.
Now let's get down to the problems:
1) The first way I tried was to send the binary of a file via JSON itself, converting the binary of the file to base64 .
The basic64 problem is that it increases (and much) the size of the file, making it unfeasible in my case, since we will allow uploading of videos.
2) Use multipart/form-data , sending the file normally, as it does in form requests, and attaching the other data previously mentioned in a "json" field, sending that data as a JSON (serialized) string.
Example:
POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: __atuvc=34%7C7; permanent=0; _gitlab_session=226ad8a0be43681acf38c2fab9497240; __profilin=p%3Dt; request_method=GET
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266
Content-Length: 554
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="json"
{"nome" : "Flor", "descricao" : "..."}
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain
Content of a.txt.
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html
<!DOCTYPE html><title>Content of a.html.</title>
-----------------------------9051914041544843365972754266--
In my opinion, this is not the standard that is already being used in all other requests, which is content-type: application/json , in addition to being a gambiarra of good sows.
3) Separate the file upload logic from the media data upload.
That seemed to me the most enjoyable, and from the little I read and talked about, it seemed more organized. But I've never done anything like that, having no implementation experience, and I'm not sure if this is a REST pattern.
One of the tips I saw, for example, was uploading the file, returning the ID of that upload, to be used to send the "extra data" for creating the resource on the server for that file. p>
My question is:
-
From the above options, which one would be closest to REST?
-
If it is feasible to implement the third option, is there any default, to set the
content-typeof the file and what type of response status could I return?
I would like some examples about the third option, since of all of these, was the only one I did not implement, and I have no idea how to do something similar.