Closed Alino closed 6 years ago
In my opinion, we should not support zip files. It would make sense only if we would need to improve bandwidth optimisation.
If a zip file would be uploaded, the server would need to separate each file inside it, into new Assets. But the Assets would lack information like 'isReference, sourceLanguage, encoding' and probably Tasks that should be associated with it.
So to me, it makes more sense to create individual Assets with POST /job/:parentid/asset
and then upload a single file into it with POST /job/:parentid/asset/uploadfile'
If somebody is going to upload too many files, he could make a client side script.
Closing for now, but feel free to discuss further here, if you think I am missing some point. I can reopen.
Sound OK to me. this keeps things simple at the asset level for now.
The use case I was think of was when we get "packages" such as a SDLPPX file for example, where we may have many different files. But that can be handled at a different level, I'm not sure yet exactly how (especially for the delivery), but that is a separate issue.
feedback from Yves.
The API looks geared toward client applications that will send individual files.
Should we have specific behaviors expected when a client wants to submit a zip file or some kind of localization package.
For example if we submit a zip files full of XLIFF documents, a few TMs and some reference material, will the API have an expected way to handle this?