Rapid API Workshop Webinar SeriesMapping 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
Roadmap Considera>ons 1. Can You See It? 6. Some Things Will Change – API Visibility – API Versioning 2. Don’t have a Meltdown 7. Welcome Aboard! – API Traﬃc Management – API User Management 3. Keys to Your Kingdom 8. Field of Dreams – API Iden>ty, Authen>ca>on, – API Community and and Authoriza>on Audience 4. Don’t Roll Your Own 9. Show Me the Money – API Security – API Mone>za>on 5. Indecent Exposure 10. Pump Up the Volume – API Data Protec>on – API Scalability
API Lifecycle Curious Building Launching Growing Expanding • Requirements • API design • Beta customers • Scaling API • New capabilities• Business case • Policy design • Rapid iteration • Scaling processes • New markets• Prototyping • Development • Driving adoption • Managing growth • Tiered policies
API Management Technology Considera>ons vs. Lifecycle Performance and Scale Traﬃc Management Secure Access Analy>cs Developer Enablement 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 ﬁnd out ﬁrst when not) – Consider providing analy>cs to developers
API Visibility 1. Can You See It? 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 traﬃc 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 ﬁnd 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 speciﬁc message? Based on what is in a cache?
API Traﬃc 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 diﬀerence between traﬃc management and business quotas – Dont subs>tute quotas for rate limits (opera>onal traﬃc ﬂow) – Dont shut oﬀ your best customers – Consider throGling at the proxy level to protect the back-‐end. All requests are not equal – Consider throGling diﬀerently 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 Traﬃc 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 diﬀerently for your own web or internal apps vs. API traﬃc? – Do you need to buﬀer 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 deﬁne diﬀerent consump>on levels for diﬀerent service >ers? – If someone goes over the quota, what is the best business recourse? Call them up and upsell them? Or shut them oﬀ? – If you are paying for the data are you measuring this for billing and pricing? How do you monitor and respond to traﬃc 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 deﬁne ﬂexible 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 ﬂy? – What capabili>es does this oﬀer 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>ﬁcates? – 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 ﬁrewall 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 speciﬁc ﬁelds based on user rights – Eliminate speciﬁc 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>ﬁable informa>on – Credit card or ﬁnancial 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 ﬁrewall 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 Data masking – preven>ng inadvertent data exposure in API responses – Replay aGacks: re-‐sending intercepted valid data, possibly including altera>on of some ﬁelds – Removing or obscuring speciﬁc ﬁelds based on user rights – Elimina>ng speciﬁc 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 diﬀerent audiences – Versioning -‐ avoid maintaining two version – mediate to hold a previous version ﬁxed – Creden>als – mediate across diﬀerent security schemes – Mone>za>on -‐ enrich ﬁelds to create mone>zed version of API – Standardize -‐ standardize elements of mul>ple APIs to create uniﬁed experience
API Versioning and Media>on 6. Things Will Change Will you need to mediate protocols? – Do you an>cipate needing to oﬀer more than one protocol or a diﬀerent 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 diﬀerent security or creden>al schemes? (ex: from simple HTTP auth to WS-‐Security) – Do you currently write a lot of code to transform between diﬀerent 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 oﬀer more than one API, do you have a need to standardize elements of the API (header or payload)? – Do diﬀerent 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 ﬁelds 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) – Deﬁne common user proﬁles 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 oﬀer 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 deﬁning >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 aﬃliates? – 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 proﬁles 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 oﬄine 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 ﬁnd 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 oﬄine 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 ﬁrst 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 reﬂected 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 ﬁts 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 speciﬁc SLA, rate limit, or oﬀer priority access to a priority partner? – If the partner wants any change in the API protocol or content – do you need to support a diﬀerent API code-‐base? – Is there a way to create a transforma>on layer to handle and scale this? – Do you need to buﬀer 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 traﬃc away from the back-‐end Oﬄoading – 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 oﬀ if they consume too much volume? – Do you have a way to control API traﬃc in case you are unable to handle the volume at some point? – Is this consistent with your threat detec>on infrastructure? Oﬄoading – Are you protec>ng the applica>on servers bby oﬄoading 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? 6. Some Things Will Change – API Visibility – API Versioning 2. Don’t have a Meltdown 7. Welcome Aboard! – API Traﬃc Management – API User Management 3. Keys to Your Kingdom 8. Field of Dreams – API Iden>ty, Authen>ca>on, – API Community and and Authoriza>on Audience 4. Don’t Roll Your Own 9. Show Me the Money – API Security – API Mone>za>on 5. Indecent Exposure 10. Pump Up the Volume – API Data Protec>on – API Scalability
Rapid API Workshop Webinar SeriesMapping 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
THANK YOU Ques%ons and ideas to:@gbrail @landlessness @apigee