You question was not 100% clear. API Manager's APIs are secured using basic auth now. Just establish a session & invoke the operations you need to publish the APIs. That should be the way to proceed.
On Tue, May 14, 2013 at 12:03 PM, Sriragu Arudsothy <[email protected]>wrote: > 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 >> >> > -- /sumedha m: +94 773017743 b : bit.ly/sumedha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
