IMO we should clearly identify what API meta data and run time data. Then we can identify what we need to consider for migration. If its single API import export we can consider metadata. If its platform migration we need to migrate both meta data and run time data.
*Meta data:* API definition, Images, documents, tags, API scopes, attached sequences. Handler details *Run time Data:* Comments, rating, subscriptions, stats, Thanks, sanjeewa. On Fri, Nov 21, 2014 at 4:01 PM, Joseph Fonseka <[email protected]> wrote: > Hi Lasantha > > IMO API comments and subscriptions should not be in the import/export it > should be only limited to API definition , Management info and the > documents. If you are exporting subscriptions it will require you to have > the exact apps and users in the imported destination as well which will > complicate the implementation & usage. > > But as you mention there are some meta info which is not present in the > swagger doc Ex: most of the management info like throttling and sequences > and even the endpoints cannot be mapped to swagger 1.2. Swagger 2.0 allow > you to define Vendor Extensions but for 1.2 I guess we have to find a > workaround or define the additional information in a separate file. > > Regards > Jo > > > > > > > > > On Fri, Nov 21, 2014 at 3:32 PM, Lasantha Fernando <[email protected]> > wrote: > >> Hi Jo, >> >> In that case, we will be using the swagger docs stored in registry to get >> the swagger definition when exporting and use the existing API to >> add/update when importing. I think there is a certain subset of >> metadata/information (captured after deploying the API) that is not >> captured by the swagger definition. But for this iteration, we will be only >> be focusing on the API definitions and not on other metadata that is added >> from store. Therefore +1 to go with swagger docs for keeping API definition. >> >> My only concern is whether this approach can be scaled if a requirement >> comes to capture other information related to APIs as well later (e.g. API >> comments, subscriptions etc). In such a case, can we keep the API >> definition itself in swagger format and keep any other artefacts that >> cannot be represented by swagger in a file format? WDYT? >> >> Thanks, >> Lasantha >> >> On 20 November 2014 14:36, Joseph Fonseka <[email protected]> wrote: >> >>> Hi Lasantha >>> >>> Currently the add-api accepts swagger doc to create an API. So If we are >>> using the existing services to import it is just a matter of posting the >>> swagger to the add API. >>> >>> As Ajith pointed out the other issue is with API related meta data >>> stored in DB Ex: scopes. If we use swagger we can represent them in a >>> logical way instead of scattering them in multiple files. >>> >>> Thanks >>> Jo >>> >>> On Thu, Nov 20, 2014 at 2:11 PM, Lasantha Fernando <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> On 20 November 2014 13:36, Ajith Vitharana <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Nov 20, 2014 at 1:19 PM, Lasantha Fernando <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Jo, >>>>>> >>>>>> Metadata related to the API is retrieved from registry RXT which >>>>>> stores it in XML format. Can't we put that metadata as XML as well to the >>>>>> archive and simply push it back to the registry when importing? For docs, >>>>>> we can use the swagger format. WDYT? >>>>>> >>>>> >>>>> At the API lifecycle (Design /Implement/Deploy) data going be stored >>>>> in different places at same time . Eg: like registry databse/ AM database >>>>> / >>>>> Identity database / file system (API XML). >>>>> So, directly pushing the XML format to registry will not work due >>>>> that reason. We should use same APIs used in API publisher/store to deploy >>>>> the API archives. That make consistency across all places for >>>>> creating/managing APIs. >>>>> >>>> >>>> Yes. Actually, what I meant was to keep the metadata in RXT in XML, but >>>> other related artifacts will be kept in a suitable format. Then at the time >>>> of importing, the APIs available at publisher/store will be used to deploy >>>> the archive. It won't be pushed to registry directly. Sorry for not >>>> communicating this clearly in the earlier response. >>>> >>>> Thanks, >>>> Lasantha >>>> >>>> >>>>> >>>>> -Ajith >>>>> >>>>> >>>>>> >>>>>> @Sanjeewa, >>>>>> >>>>>> +1 to consider the the single API import/export scenario. Regarding >>>>>> CApp deployer, there were some concerns raised by Sumedha in [1] earlier >>>>>> as >>>>>> well. I think the main concern was that modifications done to APIs after >>>>>> being deployed cannot be captured in a CAR file. Therefore I think we may >>>>>> have to go ahead with its own deployment model for this use case for now? >>>>>> >>>>>> Thanks, >>>>>> Lasantha >>>>>> >>>>>> [1] >>>>>> http://mail.wso2.org/mailarchive/architecture/2013-March/011049.html >>>>>> >>>>>> On 19 November 2014 23:25, Sanjeewa Malalgoda <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Most of the time users(creators/publishers) might need to download >>>>>>> their API as deployable artifact (archive) file and restore in another >>>>>>> deployment. Also we might need to move entire API platform to other >>>>>>> deployment(API, application tokens and everything). As an example we can >>>>>>> take developer environment to production movement. We we might need to >>>>>>> address both of these issues at some point. >>>>>>> When we implement this solution we can let users to download >>>>>>> deployable API artifact and redeploy it with deployer (like we deploy >>>>>>> capp >>>>>>> or web app). Also check in -check out client to move entire deployment >>>>>>> with APIs , applications and run time data would be other possible >>>>>>> solution >>>>>>> (something similar to registry check-in checkout client). >>>>>>> >>>>>>> IMO we should consider single API import/export and deployment >>>>>>> movement when we plan solution. Also it would be ideal if we can use >>>>>>> CApp >>>>>>> deployer model for this solution. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeewa. >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 19, 2014 at 9:05 PM, Joseph Fonseka <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Lakshman >>>>>>>> >>>>>>>> In which format will the exported meta data added to archive ? >>>>>>>> >>>>>>>> IMO Swagger would be a good option for this. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Jo >>>>>>>> >>>>>>>> On Wed, Nov 19, 2014 at 4:59 AM, Uvindra Dias Jayasinha < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Makes sense to reuse existing APIM functionality to deploy the API >>>>>>>>> archive. >>>>>>>>> >>>>>>>>> On 19 November 2014 15:59, Nuwan Dias <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Nov 19, 2014 at 2:38 PM, Ajith Vitharana <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Nov 19, 2014 at 2:29 PM, Lakshman Udayakantha < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> We are developing an API import/export feature for API manager >>>>>>>>>>>> which has been discussed earlier as well in [1]. >>>>>>>>>>>> >>>>>>>>>>>> We have identified the following artifacts to be included in >>>>>>>>>>>> the exported file of an API for now. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The archive file structure of exported APIs will be similar to >>>>>>>>>>>> below. >>>>>>>>>>>> >>>>>>>>>>>> -- pizzaShack >>>>>>>>>>>> >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> v1 >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> docs >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> image >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> sequences >>>>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>>>> meta-info >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The UI will be presented through the admin-dashboard of API >>>>>>>>>>>> manager where the available list of APIs will be displayed. The >>>>>>>>>>>> user will >>>>>>>>>>>> have the ability to select one or many APIs and create an archive >>>>>>>>>>>> with the >>>>>>>>>>>> selected APIs. After the archive is created, the user will be >>>>>>>>>>>> provided with >>>>>>>>>>>> a download link to download the archive. Please refer below image >>>>>>>>>>>> as the UI. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> How do we deploy that archive to other environment ? Eg: export >>>>>>>>>>> from Dev environment and import to Test/Prod. >>>>>>>>>>> Do we plan to introduce some deployer to import that archive ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Plan is to actually use the existing APIs to deploy them. For >>>>>>>>>> example, use the existing addAPI/updateAPI functions to create the >>>>>>>>>> APIs, >>>>>>>>>> add documents, etc. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Ajith >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] [Architecture] Export/import APIs? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://mail.wso2.org/mailarchive/architecture/2013-March/011049.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Lakshman Udayakantha >>>>>>>>>>>> WSO2 Inc. www.wso2.com >>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>> Mobile: *0711241005 <0711241005>* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ajith Vitharana. >>>>>>>>>>> WSO2 Inc. - http://wso2.org >>>>>>>>>>> Email : [email protected] >>>>>>>>>>> Mobile : +94772217350 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nuwan Dias >>>>>>>>>> >>>>>>>>>> Associate Tech Lead - 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> Uvindra >>>>>>>>> >>>>>>>>> Mobile: 777733962 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Lasantha Fernando* >>>>>> Software Engineer - Data Technologies Team >>>>>> WSO2 Inc. http://wso2.com >>>>>> >>>>>> email: [email protected] >>>>>> mobile: (+94) 71 5247551 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ajith Vitharana. >>>>> WSO2 Inc. - http://wso2.org >>>>> Email : [email protected] >>>>> Mobile : +94772217350 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Lasantha Fernando* >>>> Software Engineer - Data Technologies Team >>>> WSO2 Inc. http://wso2.com >>>> >>>> email: [email protected] >>>> mobile: (+94) 71 5247551 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> *Lasantha Fernando* >> Software Engineer - Data Technologies Team >> WSO2 Inc. http://wso2.com >> >> email: [email protected] >> mobile: (+94) 71 5247551 >> >> _______________________________________________ >> 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 > > -- *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
