Hai Sanjeewa..!
We are having a strategic discussion that how to
include the API publisher/ store jag apps to other products. Therefore, I
will update this thread after the discussion...! As far as I understand,
there will be single interceptor which decides the processing path
according to the <manageAPIs> property value.
Thanks!
Ragu
On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy <[email protected]> wrote:
> Hai Lakmali..!
>
> Yes, the above link does not work...! I moved the
> user token generation menu under the "Resources" menu in order to appear
> for Greg. Therefore the existing doc won't work. Also these changes have
> not yet been committed. I will give you , the locally built latest Greg
> 4.6.0 pack which has every thing. You can also try out some samples. When
> you get the access token via that option , that access token will be based
> on "Client_Credentials" grant type. Since the API store jag app will be
> there anyway to incorporate the light weight APIM component. Therefore the
> users are required to generate the access token via store when the <manage
> APIs> property set to true. Therefore I have to update the doc for
> generating the access token for either <manageApis> property set to true or
> false.
>
> I will update the Doc as quickly as possible.
>
> Thanks!
> Ragu
>
>
> On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda <[email protected]>wrote:
>
>>
>>
>> On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka <[email protected]>wrote:
>>
>>> Hi All,
>>>
>>> This is what we are going to add from the APIM side.
>>>
>>> 1) We will be exposing current api manager handlers related
>>> functionalities as some common packages. So this bundle can be included
>>> into any of products to get API Management without using external API
>>> Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and
>>> APIMgtUsageHandler)
>>>
>>> 2) There will be a new parameter added to carbon.xml to check whether
>>> APIManagement is enable or not.
>>> <ManageAPIs>true/false<ManageAPIs>
>>>
>>> 3) There will be a interceptor which hit first and invoke the API
>>> Management functionalities when the above parameter is set to true.
>>> Depending on the service type, aixs2 or registry api etc, this interceptor
>>> may vary.
>>> When this comes to registry, we can call this api-management
>>> functionalities that we are going to expose through new package from the
>>> JAXWS web app that Ragu has created to expose the registry api. Since
>>> generic store feature is not going to release with the up coming registry
>>> release, we may need to include APIM Store jaggery app as well in to GReg.
>>>
>> Just to clarify. With this model where we can create
>> APIs, subscriptions and generate tokens? Do we provide some UI capability
>> for this? Do we have single interceptor which handles all requests?
>>
>> Thanks,
>> Sanjeewa.
>>
>>
>>> Regards,
>>> Dinusha.
>>>
>>>
>>> On Mon, Jun 10, 2013 at 11:41 AM, Sriragu Arudsothy <[email protected]>wrote:
>>>
>>>> Hai Lalaji, Dinusha..!
>>>>
>>>> We have had a discussion about the
>>>> Light weight APIM component for other wso2 products as well as How to fit
>>>> that to the Registry REST API. According to the last discussion with
>>>> Lalaji, Dinusha and Lakmali We derived some points which I would like to
>>>> mention..! Still there is some ambiguity at the APIM side.
>>>>
>>>> 1) The current implemetation of the registry REST API requires the APIM
>>>> has to be running as a separate instance while having a configuration file
>>>> (.xml) has the API manager url endpoints in it. The above config file was
>>>> located at the Greg_Home/repository/conf.
>>>>
>>>> 2) The light weight API manager component will reside at the Greg. The
>>>> flow of request goes as below,
>>>>
>>>> Rest Client request-----> Request filter/Some filter mechanism
>>>> ------>light weight APIM ------> Registry REST API ---->Response back to
>>>> Client.
>>>>
>>>> The above path will be executed if the APIM enabled property set to
>>>> true at the config file...!
>>>>
>>>> Otherwise it request filter assumes that the request should be
>>>> processed without APIM. Request filter executes the OAuth validation logic
>>>> at the Greg REST API and proceeds to resource . Therefore the Request
>>>> filter will be functioning as a centralized routing element decides whether
>>>> the request to be processed via light weight APIM comp or alone at the Greg
>>>> REST API.
>>>>
>>>> @Lalaji and Dinusha please add anything if I miss anything.
>>>>
>>>> Thanks!
>>>> Ragu
>>>>
>>>>
>>>> On Thu, Jun 6, 2013 at 12:01 PM, Sriragu Arudsothy <[email protected]>wrote:
>>>>
>>>>> Hai All,
>>>>>
>>>>> First of all, I will explain the architecture of the REST
>>>>> API implementation. The Registry REST API has two mode of functionality.
>>>>>
>>>>> 1) Standalone mode -
>>>>>
>>>>> Straight access to Registry REST API. This has been done and working
>>>>> fine. In this case Registry provide a way to generate the OAuth Access
>>>>> token for users to access the resources. Therefore the REST calls can be
>>>>> made from any REST client with an access token to access the resources.
>>>>>
>>>>> 2) With API Manager Mode -
>>>>>
>>>>> This means the access to Registry REST API with the Externally running
>>>>> API manager instance. In here, the admin or any responsible person will
>>>>> publish the REST API via API publisher. Therefore the REST API would be
>>>>> available for subscriber / endusers. Once the access token has been
>>>>> generated, user will be able to access the Registry Resources.
>>>>>
>>>>> In this mode, There are 2 ways in which I have implemented the REST
>>>>> API invocation process. This is explained as below.
>>>>>
>>>>> 1 >> REST client ----> API gateway(REST API published at the APIM)
>>>>> ---->Registry REST API ----> Registry Resource ----> Response go to REST
>>>>> client.
>>>>>
>>>>> The above implementation works fine.
>>>>>
>>>>> 2 >> REST Client -----> Registry REST API ----> Call the REST endpoint
>>>>> at the APIM ----> return call from APIM to Registry REST API ---->
>>>>> Registry
>>>>> Resource ----> Response back to REST client.
>>>>>
>>>>> The above approach, I have the an issue to pass the payload from
>>>>> Registry REST API to APIM. I have designed the REST API in CXF/ JAx-Rs.
>>>>> The
>>>>> apache CXF Jax-Rs implementation provide a Request Handler which is an
>>>>> interceptor for the incoming requests. Therefore any request made from
>>>>> REST
>>>>> client to Registry REST API will hit the Request Handler First.
>>>>>
>>>>> Therefore, when the request go to the handler, it will check whether
>>>>> the request comes from APIM or Straight from the Client. If it comes from
>>>>> the client it will call the REST API endpoint at the APIM via an apache
>>>>> HttpClient. Therefore when I call it, I have to extract the access token,
>>>>> queryParam, payload..etc from REST client's request and add it to the
>>>>> request given to APIM. But I am able to extract the access token,
>>>>> queryparam and add it to HttpMethod and call the APIM. Request Handler
>>>>> seems that does not have a way to extract the payload ( POST/PUT).
>>>>> Therefore unable to pass the payload to the REGISTRY REST API. That is why
>>>>> GET and DELETE requests are working fine in the second approach since
>>>>> those
>>>>> do not require the payload. BUT POST/PUT requests fail to proceed.
>>>>>
>>>>>
>>>>> Therefore The CXF JAX-RS Request Handler has both the Standalone Mode
>>>>> and APIM mode execution. Therefore the standalone mode is working fine.
>>>>> But
>>>>> Which approach to be selected regarding the APIM mode to put it in the
>>>>> request handler class. Since there is an issue in Approach 2 @ APIM mode,
>>>>> It went to approach 1. According to the approach 1 the code will be
>>>>> cleaner
>>>>> than approach 2.
>>>>>
>>>>> *According to Approach 1 @APIM mode the example Request URL will be,*
>>>>>
>>>>> http://{ipaddress}:8280/{REST API context
>>>>> @APIM}/{version}/comments?path=/sample.xml.
>>>>>
>>>>> *in Standalone mode:
>>>>> *
>>>>> http:{IP address}:{greg http port}/{rest api context @
>>>>> greg}/comments?path=/sample.xml.
>>>>>
>>>>>
>>>>> The APIM team already given their words to derive an integrate able
>>>>> APIM solution for other WSO2 products. Meanwhile we heard that APIM team
>>>>> working on that too.
>>>>>
>>>>> Few days ago, Had a chat with APIM guys, They said that API publisher
>>>>> and API store will be there as it is. Therefore whoever wants to publish
>>>>> an
>>>>> API have login to the API publisher and publish an API. This can not be
>>>>> done automatically during the server starts up.
>>>>>
>>>>> This is all about the integration part of REST API with API Manager.
>>>>> @APIM please let us know the current stage of your solution.
>>>>>
>>>>> Thanks!
>>>>> Ragu
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Dinusha Dilrukshi
>>> Senior Software Engineer
>>> WSO2 Inc.: http://wso2.com/
>>> Mobile: +94725255071
>>> Blog: http://dinushasblog.blogspot.com/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *
>> *
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
