API Consumer Gateway Layer

[Amit Shah]

Hello,

We have a java ee based enterprise web application and we consume many third-party web api's in our application. I would like to get insights into how can I introduce a gateway layer that can intercept all the outgoing API calls for cross-functional benefits like security, caching, billing, policy setting etc. Are there any real-world examples that I can have a look at?

Thanks,

Amit.

[Chris Mullins]

Have you looked at the API Gateway products on the market? Apigee, Azure API Management, and Amazon's API Gateway. All of these would likely reduce the amount of work you need to do and offer features suchj as security, billing, policies, caching, and metrics. 

Cheers,

Chris

[Robert Johnson]

Hi,

My team and I built something similar for a healthcare company's platform to connect real-time transactions with a few of their strategic partners. We used Apigee for the Gateway.

It's pretty straightforward and Apigee policies can be used for the caching, security, etc. It was great because using Apigee also provided easy to configure analytics. We are currently writing a case study for it and should have it available soon.

For your specific scenario, one approach would be to, from within your app, create a new endpoint on your gateway, replace one API at a time, and mandate to your team that all new external API's go through the Gateway. Of course you'll want to explain why it's the right thing to do! :)

Regards,

Robert

CTO
Cloud 5 Systems
www.cloud5systems.com

[Ed McPadden]

We evaluated Apigee and Mulesoft and ended up going with Mulesoft. Both offerings were very good. In the end, for us, Mulesoft's Anypoint/cloud hub was a better fit since we already use Mulesoft's ESB product. It also didn't hurt that it was a lot cheaper for a similar offering.

I was also very impressed with Apigee especially their support. Both solutions are very highly rated by Gartner so you really can't go wrong with either.

They both seem to fit slightly different needs.

[Leland Johnson]

We looked at Apigee and others and chose it for its ease of use and the out-of-the box policies for metrics and security. I think it would be worth evaluating for your use cases.

[MattM]

Hi Amit,

I see a lot of helpful feedback from people on API Gateways in general.  However, these are usually deployed as reverse proxies for API providers.  I want to make sure your original question is addressed...  I've worked with a number of companies on forward-proxying APIs as you describe.  In many cases, this is done within the context of OAuth or single sign-on (e.g. connecting into Salesforce APIs).

In terms of examples, are you looking for the online implementation, or some case studies?  Please feel free to connect with me directly if you would like to discuss more.

Thanks, m@

[Srinivasa Addepalli]

I also thought that Amit is asking about API Gateways that support forwarding proxying.

Forward proxies have challenges in looking deep into the SSL traffic. In case of reverse proxies, this is kind of simpler as reverse proxies can be configured with certificate-private key pairs of servers. 

Interesting to know how this is being solved in API gateways as forward proxies.  There are solutions like SSL visibility appliances from companies like bluecoat.   Do API gateways work with these kind of appliances?

Thanks

Srini

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Amit Shah]

Yes, you got it right. I am looking for a forward proxy that proxies all the third party API calls that are being made by my enterprise web application. It would be great if you could elaborate more on how they could be implemented?

I assume Apigee, Mulesoft or any other solutions would be more focusing on helping API providers as reverse proxies. They would not be able to act as a forward proxy that I am looking out for, right?

Any online implementations or case studies detailing on how are forward proxies implemented would be helpful.

Thanks!

[Robert Johnson]

Hi Amit,

Apigee (and likely others) can absolutely be used as a forward proxy to call external APIs from within your application, and that is the specific use case I was referring to in my previous post. 

In our use case there was an internal enterprise application and platform that called to protected endpoints we configured on Apigee. From within Apigee we created some business logic and callouts to secured third-party API's.  The responses were then returned back to the enterprise application.

Additionally, all of the caching and security was configured and maintained inside Apigee -- which created a layer of abstraction.  The caching greatly helped to reduce the calls to the third party APIs.  We also configured and captured Analytics for all of the API calls. 

Again, I recommend going through a POC with one service.  From there you can create a strategic roadmap and timeframe for replacing all the API calls.

Unfortunately our case study isn't quite yet ready, but please feel free to contact me offline with any questions. 

Regards,

Robert

CTO

Cloud 5 Systems, LLC

www.cloud5systems.com

[Yahya Johnson]

We use IBM DataPower appliances in our DMZ for API proxies. They offer cloud hosted instances as well.

--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/HBLnWCdCAAY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+...@googlegroups.com.

[Amit Shah]

I would like to revive this discussion by sharing details about my experiences on using WSO2 as a forward proxy. By applying the learning's from this thread, I tried out configuring WSO2. What I understand is WSO2 can act as a ESB where we could define proxies for each API's we call in our software and update the code to make a call to this proxy instead of the actual service. I am yet to explore how to set up a common security & billing layer on this ESB set up (I doubt the possibility of this) but as such I could see caching & monitoring layers centralized. 

I am trying to list down the key benefits we could gain by having a forward API proxy in our infrastructure. I could see caching, monitoring and logging being centralized from the WSO2 test. Reading more on this topic I understand that such a forward proxy could help in 

• rate limiting
• quota management - Enforce usage quotas on users to manage capacity or charge
• policy management
• request batching - Enable batch request processing for your API clients to minimise calls they need to make to your API, both synchronous and asynchronous supported
• data type conversions - perform data type conversions i.e. from SOAP to REST or vice versa
• Anything else?

These are from my theoretical research. I request the experts to share their insights on whether these are practically possible to be implemented through a forward proxy? If so, kindly share some guidelines on how can I proceed next. Any experiences with Tyk, Kong tools would be very helpful.

Thanks,

Amit.

[Danielle Felder]

If you're still looking, you might also find real user reviews for these and other major API management solutions on IT Central Station to be helpful.

Users interested in these solutions also read reviews for CA API Management. This user writes, "The benefits are rapid development and deployment of APIs, which means that your information, your ability to handle information, to receive it and to send it, to visualize it, to report on it, to get intelligence out of it, happens fast and happens with accuracy." You can read the rest of his review here.