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]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
