Is an API proxy to the API of a SaaS a bad idea?

[Neil Munro]

Hello everyone,

I would appreciate some opinions and guidance on putting a proxy in front of the APIs exposed by SaaS (e.g Salesforce.com) (where the SaaS platform is one we subscribe to, not where we are the SaaS developer/vendor).

This would be for internal apps and not something that would be exposed to external developers.

It's not for the SaaS to access our APIs but to make the SaaS APIs visible through our API gateway.

• I feel uncomfortable with the idea but don't have the experience to know if there are good technical/architectural reasons (e.g. performance) to avoid doing this (or are my concerns unfounded)? 
  
• Will it likely be against any licensing agreement (I will obviously check)?
  
• has anyone done this and if so what should we look out for?

Thanks

Neil

[Ankit khandelwal]

Hello,

For:
1. The proxy can be good candidate for implementing your own
1.1. Circuit breakers/Throttling valves,
1.2. Metering/Internal billing
1.3. Mock testing & others
2. If you are planning to switch between vendors then the proxy shields upstream consumers from the details below.

Against:
1. It is going to add latency to the actual API.
2. Proxy scalability/availability might be less than those promised in vendor API SLA
3. Probable investments in creating/fixing tools to work with the proxy instead of the actual API.


Also consider API usage volume. If the usage volume is low, then having a proxy might be an overhead, if the usage volume is high then the proxy does have its merits.
Is the API primary dependency to upstream consumers? If it is then, I think best to capture the essence of the API in the proxy implementation and expose only that.

That is all that I could think of off the top of my head.

Regards,
Ankit

[Chris Mullins]

I would fairly strongly say "no".  

By implementing a proxy, you'll be setting up your own man-in-the-middle attacks. The proxy will see the unencrypted, and likely highly sensitive data, intended for remote services. Proxy logs will likely have all sorts of Very Bad Things in them from a security perspective. 

For example, the SAAS APIs from Salesforce (and everyone else) is HTTPS only. For you to offer a proxy means you're created a fake cert or hacked all the clients. I suspect it's also likely to mess with CORS support, JSON-P support, and perhaps cookies, as the origins for requests would be very wonky due to the DNS hacking you would need to do for it to work. That's probably never going to fly at either a technical, business, privacy, or legal level. 

Cheers,

Chris

[MattM]

Hi Neil,

To address the divide in responses you've received from Ankit and Chris, I have two questions...

- What do you mean by "proxy"?  Do you mean a standard web proxy, or an API Proxy/API Gateway that provides application-level mediation?

- What types of API clients do you have in your environment?  AJAX, mobile, other?

Thanks, m@

[Neil Munro]

Thanks to all that have answered so far.

In response to your questions, Matt:

I mean an API proxy

We have a mixture of clients both web and mobile but this particular question came up in relation to a scenario where we'd likely have some integration middleware communicating with the SaaS platform API.

Our strategy has been "here are our APIs, come and get what you need" which is pretty normal but it doesn't quite fit where the SaaS exposes an API (and the integrator assisting is not keen on calling into our APIs). The question was raised "can't we continue to get some value from our API manager/gateway by using it as the [API] proxy to the SaaS API?"

So we have the situation where rather than the client initiating the request, it would be our back end initiating and pushing data to the SaaS API.

Thanks

Neil 

[MattM]

Hi Neil,

OK, thanks for clarifying.  Not sure which API proxy you're using, but forward proxying into cloud-based APIs is pretty common for us (CA/Layer7).  It allows you to provide more flexible/strict security to the outside world, while dealing with your own internal security schemes.  On top of that, it allows API consumers internally to go to one place (the API Management system) to get the available APIs, whether they're internally- or externally-provided.  The story would most likely be the same for whatever solution you're using.

Thanks, m@