Uploads, multipart/form-data & UploadedFile

Hey Petru,

Hm, first of all, there's no any dynamic methods, so you can't call getUuid() method on the UploadedFile instance unfortunately. But it has getContent() method, you can try to dump the content of it to see if you have that UUID value there. Probably, with some extra steps you can decode and get that value from the content. Another possible way, I think you can create a custom class that will extends UploadedFile from core, or probably better create a wrapper for UploadedFile instance - you will pass the instance of UploadedFile to it's constructor and that class will help with extracting additional info and have methods like getUuid().

Or, try to get the current Request object and look at the values it has. All additional information about the request should be there. I think dumping the request with dd($request) should show all the information it has. Then, after you will know where that extra info is stored in the Request object - you will know how to get that extra data from the request.

I hope this helps!

Cheers!

Hey Arwa,

It depends on the implementation you have on your server side. In this video we're authorized and information about the current logged in user is in session. That's why we don't need to send any authorization headers. But if you're talking about not using sessions - you probably does not upload the file via usual HTML form. If you send it via the Curl or via some apps like Postman - check the docs how to add headers there. But still, you need to know how your server side works to know what exactly headers to add.

I hope this helps.

Cheers!

Hey Toshiro!

Sorry for the slow reply :). Excellent question! As you can see from the API Platform docs, handling uploads in API Platform is really a custom thing. And, to a point, I think the correct implementation depends on your exact situation. First, they advocate to use VichUploaderBundle. That's a find bundle, but I personally don't use it (it feels "heavy" to me), but there is absolutely nothing wrong with it.

Could you describe your use-case a bit so I can recommend an approach? The example in API Platform - which uses a custom controller - is a bit ugly, but it works well. And it can be used with or without Vich. If you don't use Vich, then you would basically do what we do in this tutorial inside that custom controller. Another option, depending on your situation, is to leave the "post" operation alone (don't override it and give it a custom controller) but instead to add a *new* operation (e.g. "uploadImage") that handles only the upload (and then it would have a custom controller). This is a nice way to organize things, but it would mean that you would need to API calls to fully populate your object - e.g. a POST to /api/products (to use products as an example) to send all the product data and then another POST to /api/products/image to send just the file upload. Sometimes this is not feasible for whoever/whatever is using your API, but sometimes this is *desired*, as you can easily 2 both actions (editing data and the file upload) independently.

Anyways, I'm not sure I've answered your question or not yet - let me know ;). I am not convinced that there is one approach that is always best. And one thing I don't like about the API Platform solution is that, if you override the "post" operation with a custom controller, then it doesn't work if you have an API resource that holds other fields (like Product above, where you also want to send fields like title, price, etc in JSON, but also have an upload field). That's why separating into 2 custom controllers is a good option for that case.

Cheers!

Hello weaverryan thanks for the reply! This is how I imagined it would be ... It's good to see that I was not far from the truth. Well my use case is the following: I have services on my site that each have an image, but several services can have the same image so it would be a many-to-one relationship of service to MediaObject, as well as the business model can grow later, it is possible that other entities also have other relationships with my MediaObject entity (this is thinking about the future), so I have a public and a private filesystem with the OneupFlysystemBundle because some of those future relationships may be private. The VichBundle documentation has not really helped me much, in terms of how to annotate the entities to be able to cascade "persist" the images in the POST operation for example of the Service entity, so I decided to take a risk and use other variants, for example a DataPersister and a DataProvider (for fill the contentUrl field), or maybe DTOs for these entities ... for now I'm testing. What do you think is the best variant? I came up with these solutions thinking that when I do a GET to /api/services the contentUrl field will be embedded in the json of each of the services and when I made the first DataProvider for MediaObject I realized that it did not fill the contentUrl field when I made this request ... I imagined that this DataProvider was not called, now I am implementing a DataProvider for Services to fill the contentUrl field in the GET requests that I make to the Service entity. By the way, the same thing happened to me when I created a user through another entity, for example I have an Appointment entity and an anonymous user can create an appointment through the POST operation of this entity, and the way I seek to solve this problem was to create it a temporary user (who has not been registered yet), that user needs a password but when I persisted it in a normal cascade (letting doctrine do its normal work), it did not encrypt the password field so.... I had to create a DataPersister for that entity also to encrypt the password there... When I finish any of the solutions and it is working correctly and above all "have no doubts about it" I will share it here since I really have not found any example of this anywhere!. Thanks for your help Ryan I'm learning like A LOT!!! thanks to all the team!!!

Hey Toshiro!

Sorry again for my slow reply!

What do you think is the best variant? I came up with these solutions thinking that when I do a GET to /api/services the contentUrl field will be embedded in the json of each of the services

I DO like the idea of being able to make a GET request to /api/services, and having a contentUrl property there, even if in reality, the Service has a ManyToOne to MediaObject and THAT holds the information about where the image is stored :). It's nice to me (but subjective) then returning an embedded "media" field with another embedded "contentUrl" field. But, that just depends on your taste, and if there were other important fields on MediaObject that you wanted to expose, then it makes more sense :).

You mentioned that the data provider was not called on MediaObject when you make a request to /api/services. That is correct. The data provider is only called to "fetch" the "top-level" resource. In this case, the "Service" object. Once that has been fetched, even if you exposed a "mediaObject" field, API Platform simply calls $service->getMediaObject() to fetch that item. There is no data provider involved. We talk a bit about that here - https://symfonycasts.com/screencast/api-platform-security/filtered-collection - that's a collection property, but we talk about how the method is called directly, there is no extra query or data provider called for this. So, if you did want to add a mediaObject.contentUrl field to your service, that logic would need to live in the data provider for the Service: it would call ->getMediaObject() and then populate the contentUrl field on that object.

By the way, if you have a MediaObject relation on several entities and want to convert all of them to have some contentUrl field, you could create an interface - e.g. HasMediaObjectInterface - with a getMediaObject(): ?MediaObject method on it. Then, you could create a custom data provider that operates on all classes with this interface. The only tricky part (and this IS unnecessarily tricky currently) is that you would need to inject the entire "data provider" system and call it after you added the field so that the "normal" data provider could be called (in case you already have other custom data providers for those classes). To avoid recursion, your supports method would need to somehow know that it has already been called and return false the second time. It's kind of annoying :/.

for example I have an Appointment entity and an anonymous user can create an appointment through the POST operation of this entity, and the way I seek to solve this problem was to create it a temporary user (who has not been registered yet), that user needs a password but when I persisted it in a normal cascade (letting doctrine do its normal work), it did not encrypt the password field so.... I had to create a DataPersister for that entity also to encrypt the password there

Yep, this is the same problem with the data providers! The data persister is only called for the "top level" object that you are persisting - it's not called for any sub-items :).

Cheers and good luck!

It was really difficult to come up with a working example because the documentation is not very clear on this issue and I am not that good with api platform yet so..., weaverryan what do you think of this solution? Do you have any suggestion? I hope this help someone!! Cheers!!!

Well it seems that my solution was not uploaded correctly ... I think I'd better do an example on my Github page and share the link, it seems that it was too long ...

Hey Toshiro!

Yea... I don't see it here - sorry about that :/. I you link to something else, like GitHub, I can check it out.

Cheers!

Hey @Alex

Are you getting an error when uploading a file? I'm asking because you should not worry about the default temporary directory. Symfony uses the built-in php function that detects the temporary directory based on your OS

Cheers!

Hi!
No I'm not getting any error, just asking because that difference!
Thanks for clarifying!

Regards

Hey @CuriousPete!

I like that you were interested enough to ask that question :). I used Charles - the debugging proxy - it catches all traffic and you can see the raw body :).

Cheers!