On Tue, Aug 2, 2016 at 9:42 PM, Janaka Ranabahu <[email protected]> wrote:
> > > 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. > If we develop this as a library, someone who wants to have this as a rest API can write a simple jax-rs (or similar) using the library as a dependency. Someone who's interested in using this as a CLI can do that too. That's what I (and I think Jo too) mean by saying we're expanding possibilities by developing this as a library. If we limit this functionality to a REST API, users will basically be forced to use it without any other options. > >> 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. > I personally don't like that option. We already have code that creates and fetches APIs within the system. If we're going to introduce more core methods into our code for the import and export functionality, chances are that we'll end up with duplicate code (two paths at least) for creating and fetching APIs. I'm pretty sure we'll at least introduce some conditional checks here and there to identify whether this is an import/export related request or not. IMO its important to have a single and simple piece of code for API creation, fetching, etc because it makes things a lot easier in terms of maintainability and testability as well. > > 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 > <%2B94%20718370861>* > > Lean . Enterprise . Middleware > -- 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
