Hi all, I think its best to publish the API at server start-up. This is because the DB can be cleaned at start-up etc, and asking someone to add the whole thing manually is also not so usable. However, I think what Nuwan suggests is also good, because the admin needs to decide as to whether these APIs get published or not. I think we need to have it in the CREATED state too.
Thanks, Senaka. On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta <[email protected]>wrote: > Hi Nuwan, > > > On 19 July 2013 12:19, Nuwan Dias <[email protected]> wrote: > >> Hi, >> >> I think the API should initially be in a created state rather than being >> in a published state. The admin or whoever responsible should publish it >> through the publisher. >> >> We also need to make this a generic solution so that it works even with >> external API Management. When the API is added to the registry, it will be >> visible on the publisher (external). And when the admin goes and publishes >> it, the API will then be deployed onto the Store and Gateway. >> > > +1. Agree. > > Thanks, > Lakmali > >> >> Thanks, >> NuwanD. >> >> >> On Fri, Jul 19, 2013 at 12:10 PM, Lakmali Baminiwatta >> <[email protected]>wrote: >> >>> Hi all, >>> >>> We have completed the implementation of the Embedded APIM functionality, >>> to manage GREG Rest APIs. We need to clarify how are we going to publish >>> the GREG Rest API. Publishing the API includes following tasks, >>> >>> - Add the API artifact to the registry >>> - Add the API to the APIM database >>> >>> So we have three options to publish the API. >>> >>> 1. Admin manually create the API and publish through API Publisher app. >>> (This is what we do at the moment) >>> >>> 2. Publish the API at the server startup. >>> But since this is a one time operation, there will be an >>> overhead at each server startup, in checking whether the API has already >>> published. >>> >>> 3. Publish the API at the GREG pack build time. >>> >>> What would be the best option to procede with? >>> >>> Thanks, >>> Lakmali >>> >>> -- >>> Lakmali Baminiwatta* >>> * >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> blog : lakmali.com >>> * >>> * >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Nuwan Dias >> >> Senior Software Engineer - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> > > > > -- > Lakmali Baminiwatta* > * > Software Engineer > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > blog : lakmali.com > * > * > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- * <http://us13.wso2con.com/> * * * *Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
