Hi All, +1 for implementing separate APIs for "images, PDFs etc". and application "binaries".
URL : http://localhost:9763/api/appm/publisher/v1.0/apps*/static-contents* Use of "static-contents" quite ambiguous IMO. Isn't a compiled "binary" itself a *static* content? How about using *resources* instead? It would derive the real use case of the images, PDFs etc which are supposed to be resources for the application. http://localhost:9763/api/appm/publisher/v1.0/apps/binaries http://localhost:9763/api/appm/publisher/v1.0/apps/resources <http://localhost:9763/api/appm/publisher/v1.0/apps/resources> Regards, ~Rasika On Fri, Apr 8, 2016 at 2:36 PM, Chanaka Jayasena <[email protected]> wrote: > +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 > > -- With Regards, *Rasika Perera* Software Engineer M: +94 71 680 9060 E: [email protected] LinkedIn: http://lk.linkedin.com/in/rasika90 WSO2 Inc. www.wso2.com lean.enterprise.middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
