Download Web API eBook: http://bit.ly/1mjlhkT
Watch the webcast: http://youtu.be/LgbDCcnF6m4
Listen to the webcast: http://bit.ly/1nES3uC
Digital enterprises have developed powerful playbooks to address the needs of rapidly evolving consumer-facing API and app programs.
But can these external strategies be effective as “internal” API programs that enable apps for employees and strategic business partners? Can the range of services within an organization be managed using the same “API-first” strategies that have been successful in external programs? Which best practices should be employed?
Join Chris von See and Bala Kasiviswanathan to explore how Apigee Edge and an API-first architecture form a foundation for managing internal use cases.
- internal use cases that benefit from an “API-First” architecture
- implementing internal API programs that manage internally focused apps
- surmounting challenges that arise in the service exposure layer
- the proper hosting model for your business needs
6. CC-BY-SA
The Nature of API Relationships
API relationshipCuration Control
Consumption Exposure
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
6
7. CC-BY-SA
The Nature of API Relationships
API relationship
“External”
API program
Curation Control
Consumption Exposure
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
7
8. CC-BY-SA
The Nature of API Relationships
API relationship
“External”
API program
Curation Control
Consumption Exposure
“Internal”
API program
Open adoption API
consumers
Business partners
Internally-developed
applications
Internal-only business
systems
8
9. CC-BY-SA
“API First”
9
• API adaptations needed for
apps
• Enable developers for
business
• Security for app-to-API
• App and behavior analytics
• APIs architected for
abstraction
• Enable developers for API use
• Security for API-to-backend
• API analytics
APIAPI
API consumption API exposure
API tier ServicesApp
Analytics
10. CC-BY-SA
External API programs Internal API programs
Comparing External and Internal API Programs
• For open-adoption APIs, developer
outreach/evangelism is important
• Exclusively externally-accessible APIs
• Developer support resources (docs,
tools, etc.) all open
• Security on untrusted developers is
tighter
• Tighter resource access controls and
constraints are an integral part of the
developer relationship
• Monetization is often an important
aspect
• API capacity is usually shared
• Design is often optimized for specific
use cases
• Normally no evangelism except internal
• Combined externally and internally
accessible APIs
• Some developer support resources not
available externally
• Security constraints may be
implemented differently
• Resource controls may be substantially
loosened, at the risk of possible (and
inadvertent) over-consumption
• Monetization is rarely important, but
resource accounting may be
• API capacity can be shared or
dedicated
• Design is more general in nature
10
11. CC-BY-SA
Thinking “Internally” about API Consumption
• Consolidate interaction channels at the API tier
• Develop a strategy for leveraging things you already know in reusable ways
• User interactions
• Social media data
• Establish mechanisms for bi-directional data sharing that don’t necessarily involve APIs
• Backend-as-a-Service
• State data
• Re-evaluate authentication, authorization, resource allocation access scope definitions, and
threat protection
API Consumption
API
API Tier ServicesApp
API
API Exposure
11
12. CC-BY-SA
“Internal” Consumption Case Study: Apparel
12
The challenge:
• Be a social brand and control the social conversation
• Enhance the customer experience by building an application that brings disparate customer data
sources together to help employees personalize customer shopping experiences
Apigee infrastructure
Web Mobile Point of sale
B2E application
13. CC-BY-SA
Thinking “Internally” About API Exposure
13
• Ensure that you have visibility into the ways that services or systems interact for:
• Point-to-point interactions
• Operational visibility
• Resource accounting
• Business continuity
• Auditing
• Elimination of redundancy
• Consistency in API contracts can facilitate consumption-layer development
• Evaluate your API versioning and deprecation strategy in order to avoid “gut-
wrenching” change
• Build authentication into even your origin server interactions
• Think about ways to share data across APIs and services
API Exposure
API
API tier ServicesApp
API
API Consumption
14. CC-BY-SA
“Internal” Exposure Case Study: News and
Information
1414
The challenge:
• Build a shared service to integrate siloed business units
• Allow leveraging of services across business units without point-to-point integration
• Maintain visibility into and understanding of service usage
• Build a resource accounting model based on service consumption
Shared Apigee infrastructure
Business unit one Business unit two Business unit three
15. CC-BY-SA
• There’s a need to get “out of the box” and start thinking of APIs in ways
beyond the traditional external API program.
• This new “internal API program” can be thought of in terms of the “API
first” architecture and the distinctions drawn between API consumption
and API exposure.
• Both perspectives can benefit significantly from key functionality
available in the “API tier”
– Visibility through analytics that can give a clear understanding of service
interactions and help to avoid nasty surprises
– Control and threat protection through common authorization/authentication
and threat protection
– Shared state that facilitates building an optimal user experience
– Backend-as-a-Service capabilities to support API consumption and provide
an additional data-level integration capability
The Take-Aways
15