Publishing APIs from GREG is already implemented..We just do a POSTing,..?
On 13 May 2013 22:20, Supun Malinga <[email protected]> wrote: > Hi, > > Few questions to clarify.. > > On Mon, May 13, 2013 at 12:25 PM, Sumedha Rubasinghe <[email protected]>wrote: > >> I think the confusion here is due to not treating following three aspects >> separately. >> - Runtime API access (via gateway, key management & stat publishers) >> - API Publish process (involves publisher) >> - Subscription process (involves store & key issuing functionality) >> >> Here is what I feel what need to happen. >> >> Preconditions: >> 1. G-Reg already has a REST endpoint >> >> >> API publish process involves following: >> 1. creating API configuration programmatically & deploying it >> 2. writing API definition to API Manager's governance registry >> 3. Writing a record of the API into API Manager database >> >> API subscription process involves following: >> 1. Subscriber (carbon user) signing in >> 2. writing application record to API Manager database >> 3. writing subscription record to API Manager database >> 4. writing generated keys to Identity database >> >> Gateway: >> 1. Validate the access token against Identity database >> 2. publish stats, throttle, etc >> >> >> If we are to have complete API management (all three aspects) happening >> with a single G-Reg node, I don't see any other option than packing >> everything together. >> >> But what I feel most practical is, outsourcing everything related to API >> Management to an externally deployed API Manager instance & integrate via >> AM's APIs for publish, subscribe & token validation. >> >> In this approach: >> For Gateway: >> G-Reg only need to have a servlet filter listening to requests going to >> it's REST API context. This filter should do token validation against >> external AM APIs >> > > For gateway why can't we simply ask users to talk to the api published in > the AM? > > >> >> For Publishing: >> During first server start up, access AM's publishing API & create an API >> representing G-Reg's REST API >> >> For subscription: >> If a G-Reg users want to access the API programmatically, provide >> generate token button within G-Reg. Then call AM API & get an access token >> generated. G-Reg's user account should be used as the subscriber account. >> To make Application management simple, we can treat one G-Reg instance as >> one application & have a consumer key & a secret generated against that >> G-Reg instance. This combination will be used when that G-Reg instance >> requests access tokens for it's registered users. >> > >> There are some down sides of this approach (i.e. having one application >> for G-Reg). But IMO that simplifies things to a great deal from G-Reg PoV. >> > > Here how can we handle MTed scenario in greg..? Will the rest api same for > all tenants?. > >> >> Please invite me for any further meetings happening on this. >> >> >> >> >> >> >> >> >> >> On Mon, May 13, 2013 at 11:09 AM, Srinath Perera <[email protected]>wrote: >> >>> Hi All, >>> >>> I am still not sure what we try to do. Couple of questions. >>> >>> Cannot we just support externally running API manager and let user >>> publish registry APIs to that API manager. In which case, we do not need to >>> bundle the API manager with Greg. >>> >>> What would intercepting code do? If that only collect stats, then BAM >>> handler should do the trick. >>> >>> --Srinath >>> >>> >>> On Sun, May 12, 2013 at 1:37 PM, Nuwan Bandara <[email protected]> wrote: >>> >>>> Hi Senaka >>>> >>>> >>>> On Sun, May 12, 2013 at 12:55 PM, Senaka Fernando <[email protected]>wrote: >>>> >>>>> Hi all, >>>>> >>>>> I think we are complicating the whole thing. Let me briefly explain >>>>> what is required. For any API that will be exposed from any component, we >>>>> need a concept of API Management. The AM product involves two major >>>>> components. >>>>> >>>>> 1. The entire product (including store/publisher etc) required to >>>>> do API Management. >>>>> 2. A small interceptor/handler or something of that sort required >>>>> to enable management of a single API (let me call this an agent). >>>>> >>>>> Right now, every single API needs to be managed through AM, because >>>>> the concept of an agent is not defined and we don't have anything that we >>>>> can deploy on Tomcat, Axis2, IIS etc. - but we need to. The idea here is >>>>> to >>>>> identify that minimal subset and create an agent that can be deployed in >>>>> other products of our platform such that it can be interfaced with AM. >>>>> >>>>> Having said that, the Registry REST API is one of the APIs for which >>>>> we'd like to have AM capabilities, so we wanted to get this done as a part >>>>> of that. So, what we need is a lightweight agent and also the capability >>>>> to >>>>> do OAuth-based authentication, which is analogous to the embedded >>>>> registry/user-management which ships with each product. >>>>> >>>>> >>>> I completely agree with you Senaka. This agent is NOT bundling up API >>>> manager to GREG. I think we talked about the subject during >>>> few discussions that Apps/APIs need a way to publish stats and do >>>> management so for this we need some handler (engaging) mechanism. so if >>>> this doesn't exists right now we have to write one which can be reused in >>>> similar situations. >>>> >>>> Regards, >>>> /Nuwan >>>> >>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> >>>>> On Sun, May 12, 2013 at 9:33 AM, Nuwan Bandara <[email protected]> wrote: >>>>> >>>>>> Hi Guys, >>>>>> >>>>>> Is this the correct way of doing it ? This essentially means, future >>>>>> GREG releases will contain APIM features, which is the gateway, key >>>>>> manager >>>>>> and the jaggery apps. one of my concerns are, because of an API, GREG >>>>>> pack >>>>>> will be considerably large and also having the a gateway, publisher apps >>>>>> are not really relevant when you are simply exposing an API. >>>>>> >>>>>> IMO, if your requirement is to publish stats, you should use the >>>>>> webapp BAM stats publisher (AS folks are working on this) and you can >>>>>> have >>>>>> the key issuing and management components of IS. You can provide an API >>>>>> to >>>>>> get new keys and renew, you dont need a publisher or store for this. >>>>>> >>>>>> Just because we have the API Manager doesn't mean we have to ship >>>>>> APIM components with all the APIs we compose for our products. we need to >>>>>> have a light weight mechanism, where you can collect statistics, issue >>>>>> keys >>>>>> and also document (maybe swagger based). >>>>>> >>>>>> Regards, >>>>>> /Nuwan >>>>>> >>>>>> >>>>>> On Sat, May 11, 2013 at 6:44 AM, Sriragu Arudsothy >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hai...! >>>>>>> >>>>>>> During the second architecture review we have been decided >>>>>>> the following aspects to be added to the Registry REST API, >>>>>>> >>>>>>> 1) The API OAuth access token validation, >>>>>>> 2) BAM stats monitoring, >>>>>>> 3) Throttling policy to access the REST API. >>>>>>> 4) published to dashboard. >>>>>>> >>>>>>> Therefore During the discussion, Since the APIM has all these >>>>>>> features in it, We have been requested to use the minimal workable APIM >>>>>>> inside the GREG rather than re-implementing those features for our >>>>>>> needs. >>>>>>> >>>>>>> After the discussion, I approached the APIM team. According to their >>>>>>> suggestion, they requested to run the APIM and Greg, invoke the registry >>>>>>> REST API via the API published in the APIM. Therefore the call is being >>>>>>> sent to the published api's (APIM side) endpoint which goes through the >>>>>>> above handlers and validated, finally received at the REST API endpoint. >>>>>>> >>>>>>> Thanks! >>>>>>> Ragu >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, May 10, 2013 at 7:12 PM, Supun Malinga <[email protected]>wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Sent from my phone >>>>>>>> >>>>>>>> On May 10, 2013 5:39 PM, "Sriragu Arudsothy" <[email protected]> >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Hai...! >>>>>>>> > >>>>>>>> > >>>>>>>> > The Registry REST API has been implemented as follows, >>>>>>>> > >>>>>>>> > 1) I am running an APIM instance with Greg. >>>>>>>> > >>>>>>>> > 2) Publish an API via API publisher and specifies the Registry >>>>>>>> REST API endpoint as the Target endpoint url in the API publisher. >>>>>>>> > >>>>>>>> > 3) Subscriber Creates an Application which has the published API >>>>>>>> via API store >>>>>>>> > >>>>>>>> > 4) end user who wants to use that application will generate the >>>>>>>> access token for the application and access the Registry REST API >>>>>>>> endpoint >>>>>>>> via published API. >>>>>>>> > >>>>>>>> > Is there anyway that we can embed minimal APIM component that can >>>>>>>> accomplish the needs? >>>>>>>> >>>>>>>> IMHO the easiest way is to embed the registry REST Api into AM. >>>>>>>> >>>>>>>> As per what you have mentioned I think you would need most of the >>>>>>>> features of the AM. >>>>>>>> >>>>>>>> Anyways What you intend to achieve here is not clear. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> > >>>>>>>> > Thanks...! >>>>>>>> > Ragu >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Thanks & Regards, >>>>>> >>>>>> Nuwan Bandara >>>>>> Associate Technical Lead & Member, MC, Development Technologies >>>>>> WSO2 Inc. - lean . enterprise . middleware | http://wso2.com >>>>>> blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 >>>>>> 763 9629 >>>>>> * >>>>>> <http://www.nuwanbando.com/> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Senaka Fernando* >>>>> Member - Integration Technologies Management Committee; >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Thanks & Regards, >>>> >>>> Nuwan Bandara >>>> Associate Technical Lead & Member, MC, Development Technologies >>>> WSO2 Inc. - lean . enterprise . middleware | http://wso2.com >>>> blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 >>>> 9629 >>>> * >>>> <http://www.nuwanbando.com/> >>>> >>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://www.cs.indiana.edu/~hperera/ >>> http://srinathsview.blogspot.com/ >>> >> >> >> >> -- >> /sumedha >> m: +94 773017743 >> b : bit.ly/sumedha >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Supun Malinga, > > Software Engineer, > WSO2 Inc. > http://wso2.com > http://wso2.org > email - [email protected] <[email protected]> > mobile - 071 56 91 321 > > _______________________________________________ > 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
