URL : http://localhost:9763/api/appm/publisher/v1.0/apps*/static-contents* *+1. *In that case, we can reuse this in Document upload etc also.
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] > -- Thilini Shanika Software Engineer WSO2, Inc.; http://wso2.com 20, Palmgrove Avenue, Colombo 3 E-mail: [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
