Hai Sumedha....! I have a question,
1) the user having API publisher role or above will be able to publish the API. Therefore Shall I have an another API in the Registry REST endpoint to login to the API publisher and add the API to the API publisher. It means that the particular method in the Registry REST API calls the API publisher's login API with the credentials. Once the login is success then send an another call to add an api to the REST API endpoint which will call the API Publisher's API to add that API and change the state to published. these two calls can be bound together. If we allow the users to send the tier and tiercollection parameters with the request when add the API would be better I think, What Would you think? Thanks! Ragu On Mon, May 13, 2013 at 11:03 PM, Vijayaratha Vijayasingam <[email protected]>wrote: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
