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