Your SlideShare is downloading. ×
0
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Maintainable API Docs and Other Rainbow Colored Unicorns
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Maintainable API Docs and Other Rainbow Colored Unicorns

7,826

Published on

My talk @ OSCON covering trends and tips on maintainable API documentation.

My talk @ OSCON covering trends and tips on maintainable API documentation.

Published in: Technology, Business
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,826
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
9
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • [ yeah, s/solicit/elicit/ ] ;-)
  • Thanks to everyone who attended. I had a great time, and loved having the discussions during and after the talk. 
  • Transcript

    • 1. MaintainableAPI Docs andOther Rainbow Colored Unicorns
      Neil Mansilla
      Director, Developer Products
    • 2. Disclaimer
      The views and statements contained herein are my own (Neil Mansilla)
      and do not express the views of Mashery, Inc. nor any of its employees,
      agents, customers, and associates.
      Also, I’m not a Power Point guru, nor am I Anthony Robbins.
    • 3. Greetings!
      • Name: Neil Mansilla
      • 4. Job: Director, Developer Products
      • 5. Company: Mashery
      • 6. Email: neil@mashery.com
      • 7. Web: http://developer.mashery.com
      • 8. Twitter: @mansillaDEV @mashery
    • Mashery API Network
      • Over 100 companies rely on Mashery to manage their API infrastructure
      • 9. Over 115,000 key-holding developers
      • 10. Over 30,000 active web and mobile applications
      • 11. Billions of monthly API calls
    • Mashery API Network
    • 12. Mashery API Network
    • 13. What does
      bad documentation
      really say about
      your platform?
      Your company?
    • 14. Bad docs say to your users,“I don’t care about you.”
      Do your docs elicit any of these responses?
      “Why are these docs so awful?”
      “Don’t they realize this looks like hell?”
      “How in the world am I supposed to understand how this thing works?”
      “Do they no longer support this platform?”
      “Dude, these guys are bozos.”
    • 15. A Few Common Pitfalls That Make for Bad Docs
      http://www.atarimagazines.com/hi-res/v1n2/davidcrane.php
    • 16. Technical Overload: Yadda Yadda Yadda
      Documentation is a general term for a multiplicity of documents in a chosen mix of media and with a certain collection. Purpose of documentation is the use to support a tool or a process.
      Classical documentation is a set of documents printed on paper. Documentation (to document) also refers to the process of providing evidence.
      Documentation composure
      Documentation may include
      • written information for any read, projection or technical performing,
      • 17. data media of any format and for any reproduction,
      • 18. other content.
      Common types of documentation include user guides, white papers, on-line help, quick-reference guides. It is less common to see hard-copy (paper) documentation. Documentation is distributed via websites, software products, and other on-line applications.
      [edit] Principles for producing documentation
      The following is a list of guides dealing with each specific field and type:
      documentation in health care [5]
      thesis writing [6], [7], [8]
      Further information: Dissertation
      papers for academic journal publishing (i.e. Journal of Food Science [9] and Analytical Chemistry [10])
      Producing documentation
      Technical writers and corporate communicators are professionals whose field and work is documentation. Ideally, technical writers have a background in both the subject matter and also in writing and managing content (information architecture). Technical writers more commonly collaborate with subject matter experts (SMEs), such as engineers, medical professionals, or other types of clients to define and then create content (documentation) that meets the user's needs. Corporate communications includes other types of written documentation that is required for most companies.
      [edit] Specializing documentation
      Marketing Communications (MarCom) MarCom writers endeavor to convey the company's value proposition through a variety of print, electronic, and social media. This area of corporate writing is often engaged in responding to proposals.
      Technical Communication (TechCom) Technical writers document a company's project or service. Technical publication include user guides, installation manuals, and troubleshooting/repair/replace
    • 19. Technical Overload: Yadda Yadda Yadda
      Documentation is a general term for a multiplicity of documents in a chosen mix of media and with a certain collection. Purpose of documentation is the use to support a tool or a process.
      Classical documentation is a set of documents printed on paper. Documentation (to document) also refers to the process of providing evidence.
      Documentation composure
      Documentation may include
      • written information for any read, projection or technical performing,
      • 20. data media of any format and for any reproduction,
      • 21. other content.
      Common types of documentation include user guides, white papers, on-line help, quick-reference guides. It is less common to see hard-copy (paper) documentation. Documentation is distributed via websites, software products, and other on-line applications.
      [edit] Principles for producing documentation
      The following is a list of guides dealing with each specific field and type:
      documentation in health care [5]
      thesis writing [6], [7], [8]
      Further information: Dissertation
      papers for academic journal publishing (i.e. Journal of Food Science [9] and Analytical Chemistry [10])
      Producing documentation
      Technical writers and corporate communicators are professionals whose field and work is documentation. Ideally, technical writers have a background in both the subject matter and also in writing and managing content (information architecture). Technical writers more commonly collaborate with subject matter experts (SMEs), such as engineers, medical professionals, or other types of clients to define and then create content (documentation) that meets the user's needs. Corporate communications includes other types of written documentation that is required for most companies.
      [edit] Specializing documentation
      Marketing Communications (MarCom) MarCom writers endeavor to convey the company's value proposition through a variety of print, electronic, and social media. This area of corporate writing is often engaged in responding to proposals.
      Technical Communication (TechCom) Technical writers document a company's project or service. Technical publication include user guides, installation manuals, and troubleshooting/repair/replace
    • 22. Too Little a/k/a “Just Enough to Tick You Off”
      Method: createSituation(s3, s4, s5)
      This method creates a situation
      and takes in three parameters.
      Method: selectUserByDate(date)
      This method selects a user by a date.
    • 23. Too Little a/k/a “Just Enough to Tick You Off”
      Method: createSituation(s3, s4, s5)
      This method creates a situation
      and takes in three parameters.
      Method: selectUserByDate(date)
      This method selects a user by a date.
    • 24. Undocumented changes,deprecations.
      • Changes and deprecations that are not documented
      • 25. Code samples that no longer work as described
    • Bad Docs = Angry Developers
      http://www.flickr.com/photos/gcarvalho/142922427/
    • 26. Bad Docs = Angry Developers
      http://www.flickr.com/photos/gcarvalho/142922427/
    • 27. Happy Sys Admin Day!http://www.sysadminday.com
    • 28. Happy Sys Admin Day!http://www.sysadminday.com
    • 29. Happy Sys Admin Day!http://www.sysadminday.com
    • 30. Good API Docs
      http://www.flickr.com/photos/scorpio58/4067099731/
    • 31. Why are API docs so challenging?
      • Never a top priority(until it’s too late, and even then…)
      • 32. Initial copy can be very daunting
      • 33. Audience diversity(can’t please ‘em all)
      • 34. Dynamic platform = maintenance nightmare
    • Rethinking APIDocs Design
      • Rethinking traditional technical documentation design for APIs by asking:
      • 35. Is there a better way for developers to learn how to use my platform?
      • 36. What are the pain points developers are experiencing with my current docs?
      • 37. How can I maintain my API docs more easily?
      • 38. What kind of CMS will help us be more efficient?
    • Using Definition Files to Publish Docs
      > Traditional API Definition Formats:
      • WSDL – XML for SOAP
      • 39. WADL – XML for HTTP/REST
      • 40. Javadoc – comments in Java
    • Using Definition Files to Publish Docs
      Traditional API Definition Formats:
      • WSDL – XML for SOAP
      • 41. WADL – XML for HTTP/REST
      • 42. Javadoc – comments in Java
      > Traditional Doc Generating Tools:
    • New Web Service Definition Formats & Tools
    • 45. Google Discovery FormatJSON, RESTful APIs
      http://code.google.com/apis/discovery/v1/reference.html#resource_discovery
      URL Shortener API: https://www.googleapis.com/discovery/v1/apis/urlshortener/v1/rest
      New Web Service Definition Formats & Tools
    • 46. New Web Service Definition Formats & Tools
    • 47. New Web Service Definition Formats & Tools
      Google API Explorer is now open source
      Java/GWT
      http://code.google.com/p/google-apis-explorer/
    • 48. New Web Service Definition Formats & Tools
    • 49. Wordnik swagr FormatJSON, RESTful APIs
      http://api.wordnik.com/v4/wordList.json
      New Web Service Definition Formats & Tools
    • 50. New Web Service Definition Formats & Tools
    • 51. Tool Driven and Interactive Docs
      A New Design Pattern: Interactive Documentation
    • 52. Interactive Docs
      A New Design Pattern: Interactive Documentation
      • Learning by exploration and example
      • 53. API methods and parameters in plain view
      • 54. Parameter values, types and limits provided
      • 55. Ability to make live API calls within documentation
      • 56. Inbound call, outbound header and payload displayed useful for learning, testing and debugging
    • Mashery I/O Docs
      • Inspired by Wordnik and Etsy JSON schemas
      • 57. Inspired by Wordnik UI/UX for docs
      • 58. Built prototype in Node.js
    • Mashery I/O Docs
      http://oscon.mansilla.com:3000/usatoday - docs
      http://oscon.mansilla.com/os/usatoday.json - schema
      "usatoday": {
      "name": "USA TODAY",
      "baseURL": "api.usatoday.com",
      "publicPath": "/open",
      "auth": "key",
      "keyParam": "api_key”
      }
    • 59. Mashery I/O Docsin Production
      http://developer.klout.com
      http://developer.alibris.com
      http://developer.fanfeedr.com
      http://developer.mashery.com
    • 60. In the spirit of OSCON…
      Mashery is open sourcing I/O Docs in Node.js
      • Will be posted on Github (finishing the docs )
      • 61. Includes client interface form generator and back-end proxy API call handler (in same stack)
      • 62. Deploy on your own server in just minutes
      • 63. Released under MIT License
      • 64. Plenty of JSON schemas configured with production APIs
      • 65. Support for RESTful APIs
      • 66. Support of OAuth (w/HMAC-SHA1), key passed as parameter, MD5/SHA256 signing
    • Tomorrow, all day, API Hack Day @ Urban Airship HQ
      It’s FREE. It’s FUN. It’s FRUN!
    • 67. I/O Docs Live Demo
      Time permitting, pick simple API to build I/O Docs
      Sacrifice tweet to @demogods
      Go!
    • 68. Thank you.
      Questions (and possibly some answers)
      Contact me:
      Email - neil@mashery.com
      Twitter - @mansillaDEV
      http://developer.mashery.com
    • 69. Browser URLsHere are a list of URLs that I loaded during my presentation:

    ×