Proxy or not to proxy - 3rd Party APIs

[jaybytez]

After reading the apigee ebooks and watching many of the youtube videos, the problem we have is not about exposing internal APIs or realizing internal services as APIs, but the growing number of APIs that our client-side code invokes.  This continues to grow where direct invocations to Facebook or Twitter or Youtube APIs etc are done from within a multitude of content pages.

I come from a SOA background, so naturally I would want to proxy 3rd Party services from my internal systems.

Does this work the same way with Client-side invocations of APIs?

It seems like I should utilize a Facade layer to protect my sites from these 3rd Party APIs (versioning, caching, simplifying security, etc).

Is that the correct approach for APIs as well?  So that Client-side invocations are done to an internal representation (Facade) of a 3rd Party service?

And I have done this in SOA with an ESB or built a mediation layer in code, is it best to use a product like Apigee talks of or to build this mediation layer internally for the API mediation?

Thanks for the discussion.

[MattM]

Hi J,

We definitely see this as a growing need.  The more APIs consumed on the client side, the more there is a need for a central proxy to handle consistent security and monitoring.  It's especially important when your clients are connecting to third party APIs for which your company is the business proxy: you need visibility.  We're involved in a number of these API integrations.  The ESB analogy is apt.

Thanks, m@

[Kris Kleva]

I'll take a stab at this..

I have promoted a mashup approach when the content being displayed is already largely generated from a rest API.  Especially, when those 3rd parties are already in the cloud along with my app.

If your apps work like this... proxy away and get rid of the performance bloat that tags are imposing on the clients.

However, be careful not to lose sight of the business value those client side integrations of Facebook / Twitter / YouTube may be providing.  Many "widgets" that allow you to like, tweet our view content also come with a buffet of analytics especially written for browsers.  You may lose out on tasty marketing features provided by the integration partner by sterilizing their API behind a gateway. 

Optimally, I'd say do both in moderation.  Don't blindly rip out your Facebook like buttons without first looking into some good tag management solutions.  Proxy or get rid of the poorly performing tags and give priority to the ones that give you a competitive advantage.  

Most API Management vendors will have different approaches to accomplish this (FB / Twitter Mashups), and all of the ones I've reviewed are perfectly capable to perform what you describe (and come with examples).

 I'll leave you with this final note.  When I've considered mashups on my internal SOA, the burden of latency ends up really hurting your SLA.  The physics of moving those packets back and forth to on your internal bus will hurt your response time one way or another.  Cloud based Web API Gateways offer a big advantage here have have been purpose built for the task.    

My 2 cents.

[mehdi medjaoui]

Hi,

If you want to make a proxy for 3party client side APIs, we could give you some tips.

I'm the founder of webshell.io, a javascript proxy for integrating and mashup client-side and/or server-side APIs with. some other enterprise engineer see us as an "Web Bus Service"

Can you tell more about exactly the solution you are looking for because  the feedbacks we could share with you on what we are doing could really help you to avoid mistakes we've encoutered.

Mehdi Medjaoui

Co-founder of Webshell.io,  OAuth.io and APIdays.io Conferences

API rating agency blog

{"apis":"the joy"} Tumblr

Webshell.io blog

2013/10/31 Kris Kleva <kris...@gmail.com>

--
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/groups/opt_out.

[jaybytez]

Thanks for the response, it helps to give me some context to think about with regards to what type of integrations I should try to address by taking an inventory of those integrations and understand if those integrations provide some natural value by exposing them as the default widgets provided by the service (like the Facebook/Youtube/etc). Unfortunately the website I am working on is internally hosted and not in the cloud, even though the 3rd Party content sources are.

As I mentioned, we integrate with many 3rd party content providers and so many articles/vidoes I reviewed are around APIs and exposing those APIs externally.  Where I was leaning on the API Facade eBook was trying to understand if this solution is the best pattern for addressing 3rd Party APIs and how to protect your architecture from them.  For instance, utilizing the Twitter API directly for exposing statuses from a user (and not the Twitter Widget) exposed the site to failure when Twitter migrated to their newer version that required OAuth. Since this wasn't being done (Twitter API requests were done right in the client-side code), now with Twitter/OAuth, I need some sort of server side integration to utilize the newer version of the API.  It seemed to me that this was a perfect scenario for a Facade Pattern to mediate the changes that the API was expecting and providing the OAuth security credentials for invoking the service.

So I see what appears to be like some heavier ESB equivalent mediation layers (for APIs) and then the question becomes if to use these and where...like you discussed.  Or if it's better to create a leaner mediation layer that either lives within the same layer as my website (CMS or Web Application) or utilizing some sort of JavaScript proxy layer.  The main goal would be more around protecting when we are providing dynamic content to the website from the 3rd Party APIs/sources (effects of the service being down, authentication/authorization, changes to the API, consistent error handling, etc).  It would seem that potentially utilizing some sort of API Management or making this recommendation, I would now need to understand the scalability needs if all 3rd Party API interactions are centralized through my mediation layer and how I can provide the up-time guarantees that these 3rd Party sites like Youtube can offer (if I chose to proxy them).  This is where it at least seems better to use a custom Application Layer or JavaScript Proxy Layer that deploys alongside the website and can be treated as a single unit.  Therefore if the mediation layer is having a problem on that server...then the site/application is also having a problem and can be managed together.

I guess the next steps are how does one determine that they need an API Management Product, Gateway Product, or custom Application/JavaScript Proxy Layer.  I would assume this is by assessing the type of traffic through those APIs, any metrics around API related issues based on integrations areas that we can circumvent (security/error handling/API changes/uptime), and the general strategy for business continuity around those API integrations.

Thanks again for your time. 

[Ronnie Mitra]

Hi,

Something you might want to consider on the question of where to deploy the abstraction layer is the route to production.  In many organizations deploying code changes to production is a rigorous and expensive process compared to configuring an interface transformation on a gateway.  This can make it a lot easier to quickly adapt to changing interfaces without jumping through as many operations hoops or putting a burden on your development team.

Also, this may be nitpicking but I don't agree that you need your abstraction layer to match the uptime of YouTube.  You really want to meet the uptime of your own application and that should be trivial for a good gateway product.

Ronnie

--