+1 for having image upload API separately. Usually it's better to have a separate API for image upload to provide better experience to the user.
thanks, Chanaka On Fri, Apr 8, 2016 at 9:43 AM, Ruwan Abeykoon <[email protected]> wrote: > Hi All, > Off topic: Just another idea on file upload in UI side, can we do > something like [1] with this API? > > [1] http://www.sitepoint.com/html5-javascript-file-upload-progress-bar/ > > Cheers, > > On Fri, Apr 8, 2016 at 9:38 AM, Ruwan Abeykoon <[email protected]> wrote: > >> Hi All, >> How about >> URL : http://localhost:9763/api/appm/publisher/v1.0/apps >> */static-contents* >> >> Which says it is not just Images. We can upload PDF, Movie etc. >> I think GET has no meaning. This API should return a URI (without >> host:port/context) once the file is uploaded. >> >> >> Cheers, >> Ruwan >> >> On Fri, Apr 8, 2016 at 9:25 AM, Thilini Shanika <[email protected]> >> wrote: >> >>> If we are introducing a dedicated API for images, I would like to >>> suggest below API design for that. >>> >>> URL : http://localhost:9763/api/appm/publisher/v1.0/apps*/images* >>> HTTP Methods : POST, GET >>> Content-Type : multipart/form-data >>> >>> >>> On Fri, Apr 8, 2016 at 7:42 AM, Rushmin Fernando <[email protected]> >>> wrote: >>> >>>> I agree with RuwanA. When Thilini says, "the flows of the different >>>> upload types are different", it means that the only common aspect between >>>> these upload types is, that they use the file system for storage. >>>> >>>> So -1 for the option 1. But we, of course should re-use the file upload >>>> code in different upload types :-) >>>> >>>> Thanks >>>> Rushmin >>>> >>>> On Fri, Apr 8, 2016 at 7:16 AM, Ruwan Abeykoon <[email protected]> wrote: >>>> >>>>> Hi Dinusha, >>>>> I think option (1) poses few complications in both REST API user >>>>> perspective and the implementation perspective. >>>>> 1. Application binaries need to be placed in secured location and >>>>> allow GET access based on various security policies(This is not available >>>>> yet, but is a necessary feature in future.). few examples are, >>>>> 1.a) Reviewer need to have access, but any other person should not >>>>> until published, even he has the URL, >>>>> 1.b) Implementing One time/ time based download link >>>>> Images, PDF, etc, does not have this restriction, they can be >>>>> accessible by public with known URL >>>>> >>>>> 2. Application binary need to be analyzed for number of details >>>>> including package name, version, any meta information, malware code, etc. >>>>> However for images we need only to verify if the file type and size fits, >>>>> if ever. Also the result of the REST call is different fro App binary to >>>>> any other static content. >>>>> >>>>> Hence I think option (2) is intuitive and clear. >>>>> >>>>> Cheers, >>>>> Ruwan >>>>> >>>>> On Thu, Apr 7, 2016 at 9:55 PM, Dinusha Senanayaka <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 7, 2016 at 11:44 AM, Thilini Shanika <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We have a concern regarding the design of mobile application >>>>>>> binary/image upload API. As per the discussions we had on the new >>>>>>> design of >>>>>>> the API model, we decided to use a separate API to upload mobile binary >>>>>>> files(.apk, .ipa) including the images. Thus, in order to create a >>>>>>> mobile >>>>>>> app, we have to initially upload relevant application binary and image >>>>>>> files of app thumbnail, banner and screenshots and later the application >>>>>>> should be created with the references to uploaded binaries. >>>>>>> We have already implemented the REST API for application binary >>>>>>> upload. But we have few concerns regarding the image file upload. We >>>>>>> have >>>>>>> two options in implementing image upload scenario. >>>>>>> >>>>>>> >>>>>>> 1. Reusing the binary upload API for image upload also. But in >>>>>>> this case, we need to change the API design in order to distinguish >>>>>>> the >>>>>>> uploading file type (Whether is it is an app binary or an image for >>>>>>> screenshots, thumbnails etc) since we have separate flows of >>>>>>> processing the >>>>>>> files. >>>>>>> 2. Implementing a dedicated API for image upload only. In this >>>>>>> case, we can implement this API in order to be reused in webapp image >>>>>>> upload also. >>>>>>> >>>>>>> I'm +1 for option 1. Keep the API as >>>>>> http://localhost:9763/api/appm/publisher/v1.0/apps/binaries and >>>>>> handle all binary uploads(apks, images, documents) for web/mobile from >>>>>> this >>>>>> API, instead introducing API per each binary type. >>>>>> >>>>>> Regards, >>>>>> Dinusha. >>>>>> >>>>>>> >>>>>>> As per the offline discussion I had with RuwanA, another concern was >>>>>>> raised regarding the URL for binary upload API. The current URL is ' >>>>>>> http://localhost:9763/api/appm/publisher/v1.0/apps/mobile/ >>>>>>> <http://localhost:9763/publisher/api/mobileapp/upload>binaries'. But >>>>>>> this particular URL is mobile application specific. In that case, we >>>>>>> cannot >>>>>>> reuse this API in future, for any other application binary upload, other >>>>>>> that mobile binary upload. Our suggestion here is to rename the API as >>>>>>> http://localhost:9763/api/appm/publisher/v1.0/apps/application/ >>>>>>> <http://localhost:9763/publisher/api/mobileapp/upload>binaries and >>>>>>> making the API more generic. >>>>>>> >>>>>>> Your suggestions are highly appreciated. >>>>>>> >>>>>>> [1] - >>>>>>> https://docs.google.com/document/d/1UE7SgZGsGnOgo6CokXClc6LVtI3N0tcGeXClFOT7jIA/edit >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Thilini >>>>>>> >>>>>>> -- >>>>>>> Thilini Shanika >>>>>>> Software Engineer >>>>>>> WSO2, Inc.; http://wso2.com >>>>>>> 20, Palmgrove Avenue, Colombo 3 >>>>>>> >>>>>>> E-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dinusha Dilrukshi >>>>>> Associate Technical Lead >>>>>> WSO2 Inc.: http://wso2.com/ >>>>>> Mobile: +94725255071 >>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Ruwan Abeykoon* >>>>> *Architect,* >>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>> *lean.enterprise.middleware.* >>>>> >>>>> email: [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> *Rushmin Fernando* >>>> *Technical Lead* >>>> >>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>> >>>> email : [email protected] >>>> mobile : +94772310855 >>>> >>>> >>>> >>> >>> >>> -- >>> Thilini Shanika >>> Software Engineer >>> WSO2, Inc.; http://wso2.com >>> 20, Palmgrove Avenue, Colombo 3 >>> >>> E-mail: [email protected] >>> >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Architect,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> > > > > -- > > *Ruwan Abeykoon* > *Architect,* > *WSO2, Inc. http://wso2.com <http://wso2.com/> * > *lean.enterprise.middleware.* > > email: [email protected] > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Chanaka Jayasena Associate Tech Lead, email: [email protected]; cell: +94 77 785 5565 blog: http://chanaka3d.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
