Hi All,
On Thu, Jul 21, 2016 at 7:01 PM, Joseph Fonseka <[email protected]> wrote: > > >> One downside I see in the client-side tool approach is that it will >> result in a few http calls between the client and server instead of just 1 >> http call (as before). But still I think its fine since this is not an >> end-user type of app but rather something that will be used at a much >> smaller scale since its intention is solely to export and import APIs. >> > > We can significantly reduce the HTTP calls with some enhancements to > Store/Publisher APIs. For eg. The API list resource can be modified to send > full API metadata with an additional query parameter which will eliminate > GET requests for individual APIs. Likewise we can look at ways to support > bulk retrieval. > > Regards > Jo > > > > > >> >>> Thanks, >>> sanjeewa. >>> >>>> >>>> Therefore I don't think we need any further enhancements to the >>>> publisher or store REST APIs. And we can get rid of the current >>>> import-export REST API too. >>>> >>> I have a concern around this. What we should have is a resource/method in the REST API to import and export APIs. Why I'm suggesting this is due to the following. - Creating the archive in the client machine would require multiple HTTP calls between the client and the server. - If we are going to support bulk import or export, then the number of HTTP calls would increase depending on the number of APIs. - There should be a native support for Import/Export from the REST API. Otherwise clients who prefer to write their own tool would be forced to either use the library we give, or have to use multiple API calls to get the required information. - Shipping a different library would be problematic for customers who are trying to automate the import/export(using some tool like Jenkins or Puppet) - Shipping a client library would also mean that we are bound to use Java(or the language that supports that). What if a user want to write a C# tool for this. Then our client library would not help them a lot. - If some users write tools of their own using the library we give, if we release a new version on the import/export library, then those users have to rewrite their tools with the new version. That would be a lot of overhead for the users. Therefore my suggestion is that we expose a OAuth2 protected resource/method to import/export APIs using the REST API. This is exactly what Sanjeewa has mentioned in his previous reply. Thanks, Janaka > >>>> Thanks, >>>> NuwanD. >>>> >>>> On Thu, Jul 21, 2016 at 11:31 AM, Sanjeewa Malalgoda <[email protected] >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jul 20, 2016 at 12:33 PM, Rasika Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Thilini, >>>>>> >>>>>> Api-import-export tool performs as a separate RESTful API based >>>>>>> *tool* which consumes API Manager publisher REST API. >>>>>>> Therefore IMO it is not correct to add import-export as a resource >>>>>>> to our publisher REST API. >>>>>> >>>>>> Yes, import-export is not a generic resource. This is kind of a >>>>>> special case. My main concern is it should belongs to the *publisher*. >>>>>> >>>>>> Well, this is how I derived the api; >>>>>> >>>>>> 1. Import/Export is affected to the resources >>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId} and >>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/documents/{documentId} >>>>>> . If we consider following api >>>>>> https://10.100.7.40:9443/api-import-export-<version>/import-api. It >>>>>> does not convey that import exports are belongs to the resource "apis". >>>>>> >>>>>> 2. Then it should be; https://10.100.7.40:9443/*apis*/ >>>>>> import-export-<version>/import-api >>>>>> >>>>>> 3. Do we need sub-resource import-api? no. We can derive those from >>>>>> PUT, POST(import) and GET(export). Hence https://10.100.7.40:9443/ >>>>>> *apis*/import-export. >>>>>> >>>>>> 4. Can every user import-export APIs? no. Most of the time, publisher >>>>>> does it. Hence final api; https://10.100.7.40:9443/*publisher*/*apis* >>>>>> /import-export/. >>>>>> >>>>> I have different though on this. If we consider RMM for rest APIs then >>>>> if we followed above then we will go back to level 0. >>>>> So i believe something like this should work. >>>>> >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/apis GET >>>>> download all APIs for logged in user as archive >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/apis POST >>>>> upload API list archive and import them to system >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/apis PUT >>>>> upload API list archive and update existing APIs with new artifacts >>>>> >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/api/{api-identifier} >>>>> GET download API for logged in user as archive >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/api POST >>>>> upload API list archive and import them to system >>>>> https://10.100.7.40:9443/publisher/apis/import-export-apis/api PUT >>>>> upload API list archive and update existing APIs with new artifacts >>>>> >>>>> WDYT? >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks, >>>>>> Rasika >>>>>> >>>>>> On Wed, Jul 20, 2016 at 10:06 AM, Thilini Cooray <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Rasika, >>>>>>> >>>>>>> Api-import-export tool performs as a separate RESTful API based >>>>>>> *tool* which consumes API Manager publisher REST API. >>>>>>> Therefore IMO it is not correct to add import-export as a resource >>>>>>> to our publisher REST API. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 19, 2016 at 2:39 PM, Rasika Perera <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Kaveesha, >>>>>>>> >>>>>>>> Few suggestions on the REST API for import-export. >>>>>>>> >>>>>>>> eg :- >>>>>>>>> curl -H "Authorization:Basic AbCdEfG" -F file=@ >>>>>>>>> "/Desktop/MyAPIFolder/myExportedAPI.zip" -k -X POST " >>>>>>>>> https://10.100.7.40:9443/api-import-export-<version>/import-api? >>>>>>>>> *updateIfExists=true*" >>>>>>>> >>>>>>>> Isn't API import/export apis belongs to publisher? Or is >>>>>>>> api-"import-export-<version>" is an api on a jaggery app? >>>>>>>> >>>>>>>> How about following APIs on publisher? >>>>>>>> >>>>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId} - >>>>>>>> [already exists][1] >>>>>>>> >>>>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/documents/{documentId} >>>>>>>> [already exists][2] >>>>>>>> >>>>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export >>>>>>>> [new] >>>>>>>> >>>>>>>> *Importing API* >>>>>>>> PUT https://apis.wso2.com/api/am/publisher/v0.9/apis/ >>>>>>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export> >>>>>>>> {apiId}/ >>>>>>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export> >>>>>>>> import-export >>>>>>>> <https://apis.wso2.com/api/am/publisher/v0.9/apis/%7BapiId%7D/import-export> >>>>>>>> -> Update if exists API+Docs >>>>>>>> POST >>>>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export >>>>>>>> -> Create a new API + Docs (Gives 409 if exists) >>>>>>>> >>>>>>>> *Export API* >>>>>>>> GET >>>>>>>> https://apis.wso2.com/api/am/publisher/v0.9/apis/{apiId}/import-export >>>>>>>> -> Export API >>>>>>>> >>>>>>>> Regards, >>>>>>>> Rasika >>>>>>>> >>>>>>>> [1] >>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisApiIdGet >>>>>>>> [2] >>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdGet >>>>>>>> >>>>>>>> On Thu, Jul 14, 2016 at 5:22 PM, Kaveesha Perera <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Current import/export tool doesn't facilitate updating a imported >>>>>>>>> API. I modified the implementation of import/export tool in APIM to >>>>>>>>> update >>>>>>>>> a API once its been try to import a already imported API using APIM >>>>>>>>> REST >>>>>>>>> API. >>>>>>>>> >>>>>>>>> When a user attempt to import a existing API using *"*create a >>>>>>>>> new API*" *REST API [ 1. >>>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisPost] >>>>>>>>> , server gives out a error with code 409 stating a conflict. On it, >>>>>>>>> then >>>>>>>>> check whether the user has set the value of query parameter >>>>>>>>> "updateIfExists" to true.(Refer the following example) >>>>>>>>> >>>>>>>>> eg :- >>>>>>>>> curl -H "Authorization:Basic AbCdEfG" -F file=@ >>>>>>>>> "/Desktop/MyAPIFolder/myExportedAPI.zip" -k -X POST " >>>>>>>>> https://10.100.7.40:9443/api-import-export-<version>/import-api? >>>>>>>>> *updateIfExists=true*" >>>>>>>>> >>>>>>>>> If then, update the existing API using following REST APIs, >>>>>>>>> >>>>>>>>> - Update the existing API - >>>>>>>>> >>>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisApiIdPut >>>>>>>>> - Delete the existing API documents - >>>>>>>>> >>>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdDelete >>>>>>>>> - Add exported API documents - >>>>>>>>> >>>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsPost >>>>>>>>> >>>>>>>>> - Update document contents - >>>>>>>>> >>>>>>>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdContentPost >>>>>>>>> - Add API thumbnail by calling to the end point >>>>>>>>> http://localhost:9763/api/am/publisher/v0.9//apis/{apiId}/thumbnail >>>>>>>>> >>>>>>>>> <http://www.google.com/url?q=http%3A%2F%2F127.0.0.1%3A9763%2Fapi%2Fam%2Fpublisher%2Fv0.9%2F%2Fapis%2Ff7ac5958-e581-4631-9c39-bb7d0795cf7c%2Fthumbnail&sa=D&sntz=1&usg=AFQjCNEpM0xz1acxH3fPPubOP-RG_WhTsA> >>>>>>>>> with corresponding image file. >>>>>>>>> >>>>>>>>> else, If the value of query parameter "updateIfExists" is false, >>>>>>>>> importing action ends up giving a appropriate error message stating >>>>>>>>> API >>>>>>>>> trying to create already exists. >>>>>>>>> If there are any feedback on this procedure please reply. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Kaveesha Perera >>>>>>>>> Intern - Software Engineering >>>>>>>>> >>>>>>>>> mobile: 0716130471 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> With Regards, >>>>>>>> >>>>>>>> *Rasika Perera* >>>>>>>> Software Engineer >>>>>>>> LinkedIn: http://lk.linkedin.com/in/rasika90 >>>>>>>> >>>>>>>> [image: wso2-signature-general.png] <https://wso2.com/signature> >>>>>>>> >>>>>>>> WSO2 Inc. www.wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best Regards, >>>>>>> >>>>>>> *Thilini Cooray* >>>>>>> Software Engineer >>>>>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> >>>>>>> E-mail : [email protected] >>>>>>> >>>>>>> WSO2 Inc. www.wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> With Regards, >>>>>> >>>>>> *Rasika Perera* >>>>>> Software Engineer >>>>>> LinkedIn: http://lk.linkedin.com/in/rasika90 >>>>>> >>>>>> [image: wso2-signature-general.png] <https://wso2.com/signature> >>>>>> >>>>>> WSO2 Inc. www.wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Janaka Ranabahu* Associate Technical Lead, WSO2 Inc. http://wso2.com *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861* Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
