Upload
apigee
View
14.482
Download
0
Embed Size (px)
DESCRIPTION
Part 5 in our series of API Best Practices Webinars - on API Technology and Ops Considerations - by @landlessness and @gbrail
Citation preview
Is Your API Naked? API Technology & Opera:ons
Rapid API Workshop
Greg Brail @gbrail
Brian Mulloy @landlessness
@landlessness @gbrail
Mapping out your API Strategy
Pragma>c REST: API Design Fu
10 PaGerns of Successful API Programs
API Metrics – What to Measure?
Today: API Technology & Opera:ons
Driving API Adop>on
Rapid API Workshop Webinar Series
Roadmap Considera>ons 1. Can You See It?
– API Visibility 2. Don’t have a Meltdown
– API Traffic Management 3. Keys to Your Kingdom
– API Iden>ty, Authen>ca>on, and Authoriza>on
4. Don’t Roll Your Own – API Security
5. Indecent Exposure – API Data Protec>on
6. Some Things Will Change – API Versioning
7. Welcome Aboard! – API User Management
8. Field of Dreams – API Community and
Audience 9. Show Me the Money
– API Mone>za>on 10. Pump Up the Volume
– API Scalability
API Lifecycle
Curious Building Launching Growing Expanding
• Requirements • Business case • Prototyping
• API design • Policy design • Development
• Beta customers • Rapid iteration • Driving adoption
• Scaling API • Scaling processes • Managing growth
• New capabilities • New markets • Tiered policies
API Management Technology Considera>ons vs. Lifecycle
Developer Enablement
Secure Access
Analy>cs
Traffic Management
Performance and Scale
Curious Building Launching Growing Expanding
API Visibility
1. Can You See It? An API needs API analy>cs just like a Website needs Web analy>cs
– Understand use and misuse (oeen accidental) – Cri>cal for product managers (best and worst features) – Make sure API supports analy>cs needs (again)
Understand business as well as transac>on level usage – How do apps, developers, users and APIs relate to each other – Report on business content informa>on
Use to monitor, debug and evangelize API quality – Prove service quality to users (and find out first when not) – Consider providing analy>cs to developers
API Visibility
Who is using the API and how much are they using? – How many clients, apps, developers are out there? – How do they break down by type, region? – How does usage map to exis>ng customer or partner organiza>ons? – How do developers map to applica>ons map to customers? – What parts of the API and service are they using? – How does traffic breakdown between your own products and 3rd party products? – What the aggregate and per developer/app/customer transac>on and data volumes?
How fast and “good” is your service? – What latency are customers experiencing, by developer, customer, region, or
opera>on? – Where are errors and user experienced bugs happening and how oeen? – How is the API delivering vs. any formal SLA have agreed to or paid for? – How can you find out if a customer is having a problem (before they call you)? – How is the API usage impac>ng the rest of the plakorm or web products that also use
the same API? – Can you quickly trap and debug based on a specific message? Based on what is in a
cache?
1. Can You See It?
API Traffic Management
2. Don’t have a Meltdown An API meltdown can cause a website and business meltdown
– APIs on same infrastructure as websites need throGling – Many APIs also power the website – Proper throGling can extend capacity beyond peak
Understand difference between traffic management and business quotas – Don't subs>tute quotas for rate limits (opera>onal traffic flow) – Don't shut off your best customers – Consider throGling at the proxy level to protect the back-‐end.
All requests are not equal – Consider throGling differently based on customer, customer >er, IP,
region, ... – Can you provide customers with data so they can meter themselves? – Some messages are transac>onal and may need queuing
API Traffic Management
2. Don’t have a Meltdown What kinds of rate limi>ng do you need?
– Do you need to rate limit by developer, app, or customer organiza>on? – Can you rate limit a par>cular client (key and IP address)? – Are all messages the same or do you need to adjust based on message size, or records
per message, or bandwidth? – How do you throGle differently for your own web or internal apps vs. API traffic? – Do you need to buffer or queue requests?
Does your business need quotas on API usage? – Do you need to keep track of daily or monthly usage to measure business consump>on? – Do you need to define different consump>on levels for different service >ers? – If someone goes over the quota, what is the best business recourse? Call them up and
upsell them? Or shut them off? – If you are paying for the data are you measuring this for billing and pricing?
How do you monitor and respond to traffic management? – How will you know when someone goes over a rate limit or quota? – Are quota or rate limit overages a trend or a 'one >me thing'? – Can you define flexible ac>ons? (I.e. drop requests, do nothing, send an alert?) – Can you provide customers with data so they can help by metering themselves?
API Iden>ty, Authen>ca>on, and Authoriza>on
3. Keys to Your kingdom Understand need for Iden>ty vs. Authen>ca>on
– Example: Google Maps API (only needs ID) – TwiGer API (needs auth)
Security Lessons learned – Consider API keys for iden>ty without authoriza>on – Consider basic auth to keep it simple – Consider Oauth for server-‐server APIs based on websites – Use SSL for everything sensi>ve – Avoid session based authen>ca>on – Avoid rolling your own!
Know your audience – Enterprise? Might need SOAP, SAML, 2-‐way SSL, X.509 – Web developer? Keep It simple
API Iden>ty, Authen>ca>on, and Authoriza>on
3. Keys to Your kingdom Iden>ty – who is making an API request?
– Example: Google Maps API vs. TwiGer API – Which APIs are public opera>ons? – Which APIs are private opera>ons? – Which APIs are idempotent opera>ons? – Which APIs are potent opera>ons?
Authen>ca>on – are they really are who they say they are? – Disambigua>on but not security: API Key only – Username, password, and creden>al mapping – The basics: HTTP Basic + SSL – Session-‐based authen>ca>on: the enemy of RESTful APIs – Condi>onal Authority: The role of OAuth – Enterprise authen>ca>on: SAML, X.509, and Two-‐Way SSL – Not recommended: Custom encryp>on
Authoriza>on – are they allowed to do what they are trying to do? – Which dimensions of iden>ty are important for the API?
• User, Applica>on, Developer – Do the rights need to be dynamic? – Can user or applica>ons have their rights changed on the fly? – What capabili>es does this offer or restrict in the business?
API Security
4. Don’t Roll Your Own How valuable is the data exposed by your API?
– If it’s not that valuable, or if you plan to make it as open as possible, is an API enough to uniquely iden>fy users?
– If it is valuable, can you reuse username and password scheme for each user? – Are you using SSL? Many authen>ca>on schemes are vulnerable without it
What other schemes and websites will your API and users want to integrate with? – If your API will be called programma>cally by other APIs, or if your API is
linked to another web site that requires authen>ca>on, have you considered OAuth?
– If you have username/password authen>ca>on, have you considered OpenID? – Can you make authoriza>on decisions in a central place?
What other expecta>ons might your customers have? – If your customers are enterprise customers, would they feel beGer about
SAML or X.509 cer>ficates? – Can you change or support more than one your authen>ca>on approach for
diverse enterprise customers? – Do they have an exis>ng internal security infrastructure that they need your
API to interact with?
API Data Protec>on
5. Indecent Exposure Encryp>on – protec>ng your API data from eavesdropping
– Use SSL encryp>on if API includes sensi>ve data – XML encryp>on: securing the payload for delivery behind the firewall to a
trusted client
Threat detec>on – ensuring client API requests won’t cause back-‐end problems – Always defend against SQL injec>on: takes advantage of internal systems that
construct database queries using string concatena>on – XML aGacks: large or deeply nested XML documents which cause the backend
server to use excessive resources; If your API accepts XML input via HTTP POST
Data masking – prevent sensi>ve data exposure or mask private/premium data – Removing or obscuring specific fields based on user rights – Eliminate specific data from all responses based on origina>ng IP address – Dis>nguishing between core web applica>on access and programma>c access
API Data Protec>on
5. Indecent Exposure What types of sensi>ve data is being passed on the wire?
– Personally iden>fiable informa>on – Credit card or financial informa>on
What regula>ons or policies apply to this data? – HIPAA – PCI – Internal audit
Encryp>on – protec>ng your API data from eavesdropping – XML encryp>on: securing the payload for delivery behind the firewall to a trusted client – SSL encryp>on: securing the transport itself for all data but leaving it open once delivered
Threat detec>on – ensuring client API requests won’t cause back-‐end problems – SQL injec>on: takes advantage of internal systems that construct database queries using string
concatena>on – XML aGacks: large or deeply nested XML documents which cause the backend server to use
excessive resources – Denial of Service: repeated requests from a single client or set of clients to a given API – Header bombs: malformed headers that lead to excessive resource usage and crashes – Replay aGacks: re-‐sending intercepted valid data, possibly including altera>on of some fields
Data masking – preven>ng inadvertent data exposure in API responses – Removing or obscuring specific fields based on user rights – Elimina>ng specific types of data from all responses based on origina>ng IP address – Dis>nguishing between core web applica>on access and programma>c access
API Versioning and Media>on
6. Things Will Change Prolifera:on of API varia:ons and versions can consume many development and opera:ons cycles
– Lesson learned – Truecredit.com – calculated thousands of versions to support major partners, opted for a media>on layer
Media>on considera>ons – Protocols -‐ maintain one API endpoint and mediate protocols
for different audiences – Versioning -‐ avoid maintaining two version – mediate to hold a
previous version fixed – Creden>als – mediate across different security schemes – Mone>za>on -‐ ‘enrich’ fields to create mone>zed version of API – Standardize -‐ standardize elements of mul>ple APIs to create
unified experience
API Versioning and Media>on
6. Things Will Change Will you need to mediate protocols?
– Do you an>cipate needing to offer more than one protocol or a different protocol to what you have now? (SOAP for enterprise customers? REST or JSON for developer adop>on? )
– Do you an>cipate needing to map across different security or creden>al schemes? (ex: from simple HTTP auth to WS-‐Security)
– Do you currently write a lot of code to transform between different styles of a par>cular protocol (SOAP 1.1 vs. 1.2, etc.)
– How important will it be to reduce the number of APIs versions for development and maintenance?
Version management – How oeen will you need to release upgrades to the API? – What is your process for asking customers to upgrade and how long will it take to sunset
a version? – If you offer more than one API, do you have a need to standardize elements of the API
(header or payload)? – Do different teams need to do this or does it make sense to put this capability at one
point? Message enrichment, clipping
– Will you ever need to enrich an API for a par>cular customer or class of service with more data or func>onality?
– Will you need to remove or clip certain fields for certain customers or classes of service? – How fast will you need to turnaround these requests for the business vs. your dev or
product cycle?
API Developer Onboarding
7. Welcome Aboard Make it easy
– Minimize >me to get started – Amount of informa>on for sign-‐up
Set infrastructure for adding, maintaining and dele>ng accounts – Key provisioning (API and Oauth) – Define common user profiles with preset access – Prac>ce on-‐boarding processes before launch
Do you need to start from scratch? – Use exis>ng SFA systems? (such as Salesforce.com) – Integra>on with sales, support, and ERP systems?
API Developer Onboarding
7. Welcome Aboard For on-‐boarding developers
– Do you already have a way to manage user accounts that you plan to re-‐use for your API? Or have you considered it?
– If you have, do you also wish to offer OAuth keys? – If you have no user management at all, what does a user need to do in order to sign up to use your
API? – Can they sign up quickly and easily using a web browser? – Can you simplify things by defining ‘>ers’ of users? – What kind of informa>on do they need to have access to?
For maintaining and managing accounts – Can you re-‐set passwords? – Can you delegate this ability in the case of partners who generate their own affiliates? – What user interface do you want to create for user management? – Can users do it using a web site or is there some other way? – Can you monitor their usage? Can they monitor it themselves – Can you revoke user accounts? – Do you need to implement an approval or screening process? – Do you need repor>ng and analy>cs around users – ac>ve developers, engagement and reten>on
rates? Integra>ng your API users into the rest of your business
– Does your developer ac>vity need to get mapped into your sales, support, and ERP systems? – Does your API key structure enable you to map developers to applica>ons, your customers, and their
end users? – Does user data need to be integrated with exis>ng profiles or user data systems? Can you use
exis>ng SSO (single sign-‐on) systems? – Can you create the right usage incen>ves by providing developer access to their own usage data?
API Community and Audience
8. Field of Dreams Think about Audience, Tools, Community
– Not just about the Tools or Portal – like party where you “you need to take hats and coats "
Audience (“get the word out”) – Get your content where the developers are – Plug into other developer communi>es. – Best content – code samples and examples. Release internal “hack day”
examples!
Tools ("catering, tables and chairs") – Have clear owners of developer community processes – Dress rehearse processes with the tools – Need tools for on-‐boarding, support, social media (customer outreach)
Community ("make sure people mingle") – Build create customer advocates that will go to bat for you (Hoovers example) – Best way = point out cool apps they are building – Internal developers can be best advocates (Yahoo Hack Day example) – Target both online and offline events
API Community and Audience
8. Field of Dreams Community enablers
– Do you have formal documenta>on? – Can you put it on a wiki so that developers can edit, add, and comment? – Do you have code samples on how to use the API? – Do you have a place for developers to put their own code samples and showcase their own work and
sample apps? (widgets, mobile apps, etc.) – Are code libraries needed for important plakorms? – Should these be open source? – Do you have a blog for best prac>ces and a way to get in touch with developers on important
changes (such as API version updates?) Audience and distribu>on
– Can you get awareness and distribu>on through exis>ng developer communi>es, such as any vendor (MS, Google, IBM), Plakorm (Ruby, iPhone), Independent, Directories (programmableweb)
– What Web marke>ng or SEO/SEM (Search Engine Op>miza>on or Search Engine Marke>ng/Adwords) can you do to make sure developers find you when searching for “API + your type of content or business”.
– Community support and tools Community management
– Should you have a dedicated full-‐>me employee to drive community and evangelize your product and best developers?
– Are there any offline events or meetups you should be at? – How can you recognize and promote your hardcore community members? Do you have an
evangelist that knows these folks personally? – Are you ac>vely researching their opportuni>es for revenue through recombining your services? – Is there a small group you can pay to build the first applica>ons and “prime the pump” for mass
adop>on?
API Mone>za>on
9. Show Me the Money General business and partner model ques>ons
– How is your business and revenue model supported by your API? – Does the API drive a mone>zed transac>on? – Will you ever charge for ‘pay by the API drink’ for some parts of your API? – How are your costs reflected in your API? Do you pay for any of the data you are serving
up? If so, how do you keep track of this for the business and partner? – Will large partners or deals surface where your team will need to change the API
content, SLA, protocol or content? – Is there a partner that might want to pay enough and who is large enough to drive your
team to move a way from “one size fits all?” – Will you need to create ‘service >ers”?
Enforcing unique business and opera>onal terms – How will you meter service like a u>lity, so that you can bill partners and report data
costs? – What regulatory compliance will you need to support? Do you need SOX-‐compliant
audit trails by partner? HIPPA? PCI? – How would you create and enforce a partner specific SLA, rate limit, or offer ‘priority
access’ to a priority partner? – If the partner wants any change in the API protocol or content – do you need to support
a different API code-‐base? – Is there a way to create a transforma>on layer to handle and scale this? – Do you need to buffer up or queue incoming requests?
API Scalability
10. Pump Up the Volume Are you prepared for 10, 100, or 10,000 :mes the current volume?
– May require fundamental changes to your technology and architecture.
– Do you need to deliver globally?
Caching – Reduces latency, improves throughput by protec>ng back-‐end
services – Consider caching frequent API responses
Rate-‐limi:ng and threat-‐detec:on
– Keep unecessary traffic away from the back-‐end
Offloading – Resource-‐intensive repe>>ve tasks like SSL, HTTP connec>on
management, authen>ca>on, valida>on, and compression
API Scalability
10. Pump Up the Volume Key scalability ques>ons to ask for your roadmap
– What kind of volume are you expec>ng? – Are you prepared if you get 10, 100, or 10,000 >mes that amount of volume with liGle
warning? – Are your back end servers capable of handling tens of thousands of concurrent connec>ons? – Are you monitoring response >mes and tracking them to gauge customer sa>sfac>on?
Caching – Are your back end services cacheable? – Do you have a cache that you can use to reduce response >mes?
• Between the applica>on server and the database? • Within the applica>on server? • Between the applica>on server and the range of API clients?
Rate-‐limi>ng – Do you have a way to shut a user off if they consume too much volume? – Do you have a way to control API traffic in case you are unable to handle the volume at some
point? – Is this consistent with your threat detec>on infrastructure?
Offloading – Are you protec>ng the applica>on servers bby offloading resource-‐intensive repe>>ve tasks
like SSL, HTTP connec>on management, authen>ca>on, valida>on, and compression?
What We Covered 1. Can You See It?
– API Visibility 2. Don’t have a Meltdown
– API Traffic Management 3. Keys to Your Kingdom
– API Iden>ty, Authen>ca>on, and Authoriza>on
4. Don’t Roll Your Own – API Security
5. Indecent Exposure – API Data Protec>on
6. Some Things Will Change – API Versioning
7. Welcome Aboard! – API User Management
8. Field of Dreams – API Community and
Audience 9. Show Me the Money
– API Mone>za>on 10. Pump Up the Volume
– API Scalability
Content vs. Transac>onal APIs
Mapping out your API Strategy
Pragma>c REST: API Design Fu
10 PaGerns in Successful API Programs
Today: API Metrics – What to Measure?
API Technology & Opera>ons
Driving API Adop:on
Rapid API Workshop Webinar Series
THANK YOU Ques%ons and ideas to: @gbrail @landlessness @apigee