On Tue, Aug 2, 2016 at 8:38 PM, Nuwan Dias <[email protected]> wrote: > Yes, +1. I too believe we should continue developing this as a library. > That would bring out a lot more possibilities on how this library can be > used instead of limiting it to an API and hence would serve a wider > audience. > This would not bring more possibilities but limit the possibilities we have. Import/export should be 2 core functionalists of an API. These operations are heavy ones. Doing that in a client side would add lots of overhead. We should do this on the server side and get a zip file as in the previous versions. That way we can minimize the overhead and which is a more cleaner approach.
> > The reason we had the import/export functionality as a REST API earlier > was because we didn't have a nice clean REST API for the publisher and > store. Now that we have it IMO we should utilize that instead of > introducing yet another API proxying the publisher API. > > No. What I've asked here is not to add another layer. If I understand correctly, developing this as a separate library would be like adding a abstraction layer for something we do not have OOTB. Instead what I propose is we add 2 methods to the REST API itself called import and export. I believe that import and export should be 2 core functionalists of an API instead of using multiple calls to do that operation. If you look at other products like G-Reg, their core API has methods called "dump" and "restore" which does exactly the same. Thanks, Janaka > > > > > On Tue, Aug 2, 2016 at 7:53 PM, Joseph Fonseka <[email protected]> wrote: > >> Hi Janaka >> >> On Tue, Aug 2, 2016 at 4:45 PM, Janaka Ranabahu <[email protected]> wrote: >> >>> >>> - 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. >>> >>> Given the frequency of import/export and the number of APIs in >> a typical system I do not think we have to worry about number of HTTP calls >> required to import/export from client side. >> >>> >>> - 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. >>> >> >> I agree with the above giving a HTTP API will be a more generic solution >> which can be used in many scenarios. But if we protect it with OAuth using >> it for day to day will be cumbersome since you have to deal with generating >> tokens. So if we develop a cli tool which utilize that API we can hide this >> complexity from the user. >> >> IMO we should continue on developing the import/export library which >> utilize the REST API. Then we have the flexibility of developing the >> import/export as an API, CLI tool or some other plugin if required. >> >> Thanks & Regards >> Jo >> >> >>> >>> >>>> >>>>>>> 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 >>> <%2B94%20718370861>* >>> >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- *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
