Hi Rasika, Would the name *resources* confuse with other resources (e.g. Registry, Repository Resources) etc? if not I am OK on using *resources*
Cheers, Ruwan On Fri, Apr 8, 2016 at 7:32 PM, Rasika Perera <[email protected]> wrote: > 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 > -- *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
