AFAIK word "resource" is not used for other things in AppM API URLs. So +1 for "http://localhost:9763/api/appm/publisher/v1.0/apps/resources"; URL.
Thanks. On Fri, Apr 8, 2016 at 7:42 PM, Ruwan Abeykoon <[email protected]> wrote: > 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 > > -- Sajith Janaprasad Ariyarathna Software Engineer; WSO2, Inc.; http://wso2.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
