Hi Pubudu, What will be the behavior when an api is updated
1. From API publisher UI 2. From the api artifact itself(if it is allowed). Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Tue, Feb 7, 2017 at 10:49 PM, Nuwan Dias <[email protected]> wrote: > Hi Matteo, > > To give you some context, this model is suggested for API Manager version > 3.0.0 which will be on a new Carbon platform version, version 5. Its > literarily a rewrite of the current API Manager product and hence we're > rethinking and redesigning all features. > > What we're trying to achieve here is to give the ability for APIs to be > deployed in separate zones. i.e. Internally accessible vs publicly > accessible. How we supported this earlier was by making the API Publisher > push APIs to Gateways in different zones when the APIs were being > published. But deploying APIs in the API Publishing process had its own set > of problems such as > > 1. When it was required to publish to many Gateway, the publishing process > consumed a lot of time. > 2. If the API deployment failed partially, we had to record the failures > while still changing the state of the API. The API publishers had to later > republish. > 3. If a new zone is added later, the API publishers had to republish the > APIs to the new zone. > > Most of these problems stemmed from the fact that we were using a "Push" > model of APIs instead of a "Pull". The model suggested for API Manager > 3.0.0 is a "Pull" model by which we try to achieve a lot of dynamicity and > make the API Publishing process more robust at the same time. > > Thanks, > NuwanD. > > On Tue, Feb 7, 2017 at 9:53 PM, Matteo Bordin <[email protected]> > wrote: > >> Hello >> why does not it be possible to use the feature “Environment”? >> I mean the configuration into the api-manager.xml file >> “<APIGateway> >> <!-- The environments to which an API will be published --> >> <Environments> >> <!-- Environments can be of different types. Allowed values >> are 'hybrid', 'production' and 'sandbox'. >> An API deployed on a 'production' type gateway will only >> support production keys >> An API deployed on a 'sandbox' type gateway will only >> support sandbox keys >> An API deployed on a 'hybrid' type gateway will support >> both production and sandbox keys. --> >> <!-- api-console element specifies whether the environment >> should be listed in API Console or not --> >> <Environment type="hybrid" api-console="true"> >> <Name>Production and Sandbox</Name> >> <Description>This is a hybrid gateway that handles both >> production and sandbox token traffic.</Description> >> <!-- Server URL of the API gateway --> >> <ServerURL>https://localhost:$ >> {mgt.transport.https.port}${carbon.context}services/</ServerURL> >> <!-- Admin username for the API gateway. --> >> <Username>${admin.username}</Username> >> <!-- Admin password for the API gateway.--> >> <Password>${admin.password}</Password> >> <!-- Endpoint URLs for the APIs hosted in this API >> gateway.--> >> <GatewayEndpoint>http://${carb >> on.local.ip}:${http.nio.port},https://${carbon.local.ip}:${ >> https.nio.port}</GatewayEndpoint> >> </Environment> >> </Environments> >> </APIGateway> “ >> >> So we create more than one environment, one for each “label”, the >> configuration could be: one api gateway manager for environment and any >> number of gateway for manager. >> When you deploy the API you can decide where you would like to deploy >> your API, the publisher using the admin service publish the API into the >> correct gateway, in the store you can see the url of the gateway where you >> have deployed the API. >> Probably I don not understand the requirements. >> Could you provide us a real use case? >> This is my two cents! >> >> bye >> Matteo >> >> >> Matteo Bordin >> Profesia s.r.l. - http://www.profesia.it >> via Po, 1 - 10124 Torino (TO) Tel +39 011 0120371 >> <+39%20011%20012%200371> Fax +39 011 3710371 <+39%20011%20371%200371> >> Piazzale Luigi Sturzo, 15 - 00144 Roma Tel +39 06 87811323 >> <+39%2006%208781%201323> >> Cell: +39 346 017 91 68 >> Skype: matteobordin >> eMail: [email protected] >> — >> “Profesia, innovation in action" >> >> >> >> >> >> >> >> >> >> On 7 Feb 2017, at 15:01, Pubudu Gunatilaka <[email protected]> wrote: >> >> Hi, >> >> There can be situations where we need to host public gateways for public >> traffic as well as private gateways for internal traffic. In general, there >> can be different gateway environments which serve particular APIs. The >> publisher can decide which API should be served by which gateway >> environment. >> >> The flow is as follows. >> >> <Labels based GWs.jpg> >> >> >> 1. When creating an API, the publisher can decide the labels for an API. >> Labels can be public, private, etc. Users can define labels based on their >> use cases. Once the API is published, an event is published to the topic. >> 2. Gateways are subscribed to the particular topics at the startup and >> they will receive the API publishing event. Gateways are capable of loading >> APIs on demand as well as able to load when API is published. Gateways >> should be started with a label. For an example, the public gateway should >> be started providing an argument at startup with label value public. This >> is to identify the environment. >> 3. When requesting a particular API from the publisher, the gateway >> should provide the label value. The publisher will check the available >> labels in the API and the gateway only receives the API only if there is a >> match for the given label in the API. >> 4. Key validation. >> >> In Store, there will be a REST API to get the label information which >> contains the label name and the URL of the gateway. This is used to display >> the gateway URLs in the API store. By default, it will display all the >> available environments. There is an extension point which users can use to >> restrict showing particular gateway endpoints based on the user who logs >> into the API store. >> >> *Note: *These gateway environments are not same as having Dev , QA and >> Prod environments of the API Manager deployment. Dev, QA, Prod environments >> are called stages in API Manager from C5 onwards. In a particular stage, >> there can be different gateway environments. >> >> Please share your thoughts. >> >> Thank you! >> -- >> *Pubudu Gunatilaka* >> Committer and PMC Member - Apache Stratos >> Software Engineer >> WSO2, Inc.: http://wso2.com >> mobile : +94774078049 <%2B94772207163> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >> >> _______________________________________________ >> 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 <+94%2077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
