With offline mode, will these APIs ever be synced with central API Manager?
Since there is no subscriptions, which authentication authentication mechanism we going to use for these APIs? Can't we generate the throttling tier by taking rate and quota limits from the inputs itself? On Mon, Oct 29, 2018 at 2:57 PM Sanjeewa Malalgoda <[email protected]> wrote: > I think using swagger extension is not good idea. Reason is we cannot ask > user to add custom attributes which required for us. And most of the time > users are not willing to do that because this API definition can be used > any many different systems and teams(Ex clients, server stubs, docs etc). > They all might not interested about APIM specific attributes. If we are to > fetch API definition from OAS file and fetch other APIM specific attributes > from another source then we will have to merge them carefully. We came a > across this problem many times in recent past and its good to avoid that > if possible. > > My suggestion for this is allow minimum required security validation, > throttling etc in generated gateway(can apply to all places based on pre > defined parameter). Then let users to apply throttling + security more > granular way once we take this API to API Management system. After > developer done with initial testing they will move this API to API > Management solution. > > Thanks, > sanjeewa. > > On Sat, Oct 27, 2018 at 7:28 AM Malintha Amarasinghe <[email protected]> > wrote: > >> Hi Arshardh, >> >> On Fri, Oct 26, 2018 at 11:16 AM Arshardh Ifthikar <[email protected]> >> wrote: >> >>> Hi all, >>> >>> The existing Microgateway loads the api via contacting the API Manager >>> instance that should be up and running. We are developing a feature where >>> we have given the option to setup the Microgateway without an API Manager >>> instance running. There are two aspects that the Microgateway uses the API >>> Manager during setup >>> >>> 1. Loading the Api Definition >>> 2. Fetching the Throttling Policies >>> >>> In order to decouple the the Microgateway from API Manager, these >>> aspects needs to be addressed. >>> >>> *1. Loading the Api Definition* >>> This implementation requires the user to enter at least the path of the >>> open api specification file and the endpoint of that API. If the user needs >>> additional functionality, they can provide the paths to the endpoint >>> definition and the CORS configuration json files. >>> >>> - The Open API Specification file should be given with the *-o *or >>> * --open-api *option. >>> - The endpoint needs to be given with the *-e* or *--endpoint* >>> option. >>> - If the user needs to give additional information on the endpoint >>> (ex: endpoint type), the user can give the path to the endpoint config >>> with >>> the *-ec* or *--endpointConfig *option. >>> - The user can provide the path to the CORS configuration with the >>> *-cc* or *--corsConfig *option. >>> >>> The following is the basic command to setup a new API in the >>> Microgateway with this feature implemented. >>> >>>> *micro-gw setup test-project -o /path/to/def/apidef.json -e >>>> http://localhost:9090/hello/sayHello >>>> <http://localhost:9090/hello/sayHello>* >>> >>> >> -o is typically used to specify the "output" location so can made a >> confusion at first glance. Shall we try to use a different flag? (eg : -oa) >> >> Is it possible to override the endpoint configurations you provide by -e >> or -ec after setting up and building the microgateway? Just wanted to make >> sure [1] is supported here too. >> >> [1] https://docs.wso2.com/display/AM260/Overriding+Endpoint+Information >> >> Thanks! >> Malintha >> >>> >>> *2. Fetching the Throttling Policies* >>> We store the most commonly used policies within the >>> Microgateway distribution and copy these policies to the project when the >>> setup command is executed. If a user needs to add a custom policy, the user >>> can add it to the policy directory in the Microgateway. >>> >>> Your comments and suggestions on this feature will be highly appreciated. >>> >>> Thanks, >>> Arshardh >>> -- >>> *Arshardh Ifthikar* >>> Software Engineer | WSO2 Inc. >>> >>> Email: [email protected] >>> Mobile: +94719806525 >>> Web: http://wso2.com >>> >>> <http://wso2.com/signature> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Sanjeewa Malalgoda* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 712933253 | (e) [email protected] | (b) Blogger > <http://sanjeewamalalgoda.blogspot.com>, Medium > <https://medium.com/@sanjeewa190> > > GET INTEGRATION AGILE <https://wso2.com/signature> > Integration Agility for Digitally Driven Business > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Harsha Kumara* Associate Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: [email protected] Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
