• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Your API is not a Website!
 

Your API is not a Website!

on

  • 10,802 views

 

Statistics

Views

Total Views
10,802
Views on SlideShare
1,704
Embed Views
9,098

Actions

Likes
3
Downloads
45
Comments
1

17 Embeds 9,098

http://blog.apigee.com 8829
http://apigee.com 119
http://blog.sonoasystems.com 78
http://mktg-new.local 16
https://blog.apigee.com 12
http://feeds.apigee.com 11
http://murathalici.homeip.net 7
http://mktg-dev.apigee.com 7
http://webcache.googleusercontent.com 5
http://mktg-dev.wearepropeople.md 3
http://translate.googleusercontent.com 3
http://feeds.feedburner.com 2
http://www.newsblur.com 2
http://blog-dev.wearepropeople.md 1
http://newsblur.com 1
http://ip54.216-86-157.static.steadfast.net 1
http://newsblur.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/oB_y6gl0gBE" frameborder="0" allowfullscreen></iframe>
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Creative Commons Attribution-Share Alike 3.0 United States License

Your API is not a Website! Your API is not a Website! Presentation Transcript

  • Your API is not a Website!
    9.15.11 @ 11:05 PST
    VOIP or Dial-in (see chat)
    Greg Brail @gbrail
    Brian Pagano@brianpagano
  • @brianpagano
    @gbrail
  • API Workshop Webinar Series
    (videos & slides at http://blog.apigee.com/taglist/webinar)
    Mapping out your API Strategy
    Pragmatic REST: API Design Fu
    10 Patterns in Successful API Programs
    What to Measure: API Analytics
    Is your API Naked? API Tech & Operations
    Does your API need PCI? (Compliance)
    Developers Hate Marketing: Driving API Adoption
    OAuth: The Big Picture
    “Boss, we need an API”
    Your API is not a Website!
  • Setup
    APIs seem at first like web sites without images.
    On deeper inspection that’s not the case!
    Examining the differences is a great discussion on API technology.
  • But first, how are APIs and Websites the same?
  • Image by caseymultimedia
  • How are APIs and Websites the same?
    24x7 operations
  • How are APIs and Websites the same?
    24x7 operations
    Frequent deployment
  • How are APIs and Websites the same?
    24x7 operations
    Frequent deployment
    Fast expectations
    On the Internet this is not news.
    But inside corporate IT, it is a new way of life!
    This is the case for public and private APIs.
  • So how are they different?
  • Image by lindzstrom
  • How are APIs and Websites different?
    Audience
    Longevity
    Analytics
    Security
    Integration
    Testability
  • Audience
    Websites are used by humans
    APIs are used by programmers.
    Programmers, in turn, make apps for humans.
    image by maanow
  • Why does this matter?
    Developers don’t care about images, fonts, colors, and other design elements.
    Developers do care about the “look and feel” of the API itself.
    Is it easy to develop to?
    Does it use REST appropriately?
    (according to their own definition of “REST”)
    Does it make me do anything weird?
    Does it work?
    Is it down a lot?
  • Longevity
    Web sites change all the time.
    APIs must remain compatible over time.
    image by wilhelmja
  • Why Does this Matter?
    Humans are fairly resilient to change
    We may complain…
    …but when a site design changes, we (usually) adapt
    Programs are not resilient to change
    Developers don’t want to re-write
    Old apps might not have developers any more
    Users don’t install updates right away
  • Analytics
    Most web analytics depend on the browser.
    API clients might not be browsers at all!
  • Why Does this Matter?
    API analytics can’t rely on:
    JavaScript that runs on the client
    “Beacon” URLs that get downloaded all the time
    Cookies the client must return
    API clients just don’t do these things - especially when built by 3rd parties
    You need to embed analytics on the server.
    Use what is sent in the request and only that
  • Security
    Web sites can be scraped carefully.
    APIs are extremely easy to “scrape” and automate.
    APIs and web sites need different types of security.
    OAuth for APIs, passwords for web sites,
    SSL for both!
  • Why Does this Matter?
    Since APIs are so easy to program, they are easy to ‘do damage.’
    Try to crack passwords using an API
    Download a company’s whole product catalog
    Book a whole bunch of flights to mess with pricing
    Rate limits and quotas are essential.
  • Why Else Does this Matter?
    Passwords are lousy for public APIs.
    They propagate to lots of sites that use the APIs
    They propagate to devices that use the APIs
    Consider OAuth for these cases
  • Integration
    Web sites can pull content from all over.
    APIs sit in one place.
  • Why Does this Matter?
    The architecture is just different.
    Websites can include scripts, gadgets, and images from all over the web
    APIs can’t – developers expect a few API calls to do it all
    But you can pull things together on the server side…
  • Testability
    Automated web site testing is hard.
    Automated API testing is easier.
  • Why Does this Matter?
    Any API needs to:
    Change quickly
    Remain compatible
    Perform consistently
    How do you ensure this?
    Test early and test often
    Automated regression testing is the key
    A good API should make this EASY
  • Conclusion
    A great API is not the same as a great web site.
    A great API is:
    Fast-moving, yet it never breaks the apps
    Reliable, stable, and fast
    Easy to understand and program to
    Secure and resilient to failure
    You need both.
  • THANK YOU
    Questions and ideas to:
    @apigee
    @gbrail
    @brianpagano