O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Going to Infinity and Beyond Documentation with OpenAPI

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 36 Anúncio

Going to Infinity and Beyond Documentation with OpenAPI

Given at DevXCon SF 2018. Another version focused on technical writers was given at API the Docs Paris 2018.

Having an OpenAPI Specification (OAS) is a useful document for improving the developer experience of an API. The most common use case being the ease of generating API reference documentation, but it overshadows some additional benefits that you can gain from adopting the OpenAPI Specification. This talk will delve into the hidden value of the OpenAPI Specification, and how you can employ it to your advantage.

Some topics include: Design-first APIs, Mocking, Feedback Loops, Testing, and more.

Given at DevXCon SF 2018. Another version focused on technical writers was given at API the Docs Paris 2018.

Having an OpenAPI Specification (OAS) is a useful document for improving the developer experience of an API. The most common use case being the ease of generating API reference documentation, but it overshadows some additional benefits that you can gain from adopting the OpenAPI Specification. This talk will delve into the hidden value of the OpenAPI Specification, and how you can employ it to your advantage.

Some topics include: Design-first APIs, Mocking, Feedback Loops, Testing, and more.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Going to Infinity and Beyond Documentation with OpenAPI (20)

Anúncio

Mais recentes (20)

Going to Infinity and Beyond Documentation with OpenAPI

  1. 1. GOING TO INFINITY AND Beyond Documentation WITH OPENAPI @TAYLOR_ATX
  2. 2. HI! ! I'M THE LEAD COMMUNITY ENGINEER AT Stoplight FIND ME ON TWITTER @TAYLOR_ATX OR TAYLOR@STOPLIGHT.IO
  3. 3. SINGLE SOURCE OF TRUTH @taylor_atx
  4. 4. SELF-DOCUMENTING APIS DO not EXIST @taylor_atx
  5. 5. WHAT IS OpenAPI Specification?(FKA SWAGGER) @taylor_atx
  6. 6. STANDARD, structured approach FOR DESCRIBING APIS THAT IS BOTH human AND machine READABLE @taylor_atx
  7. 7. "OpenAPI is a bridge to understanding and being able to communicate around using HTTP as a transport, and our greatest hope for helping [people] learn their HTTPs and 123s." -Kin Lane, API Evangelist Photo by Jonas Verstuyft
  8. 8. HIDDEN OPENAPI BENEFITS ✨ @taylor_atx
  9. 9. IT IS not JUST FOR API REFERENCES ! @taylor_atx
  10. 10. IT IS not JUST FOR API REFERENCES ▸ Development contract ▸ Prototyping and mocking ▸ Client SDKs and libraries ▸ Testing ▸ Server stubs @taylor_atx
  11. 11. YOU GET TO FOCUS ON THE good stuff ! @taylor_atx
  12. 12. TOOL FOR Collaboration ! @taylor_atx
  13. 13. TOOL FOR Collaboration ▸ Simplifies describing an API ▸ Standardizes terminology ▸ "API Fastness" @taylor_atx
  14. 14. ENHANCES Developer Experience ! @taylor_atx
  15. 15. ENHANCES Developer Experience 1. Design-First 2. Mocking and Feedback 3. Testing @taylor_atx
  16. 16. 1. DESIGN-FIRST @taylor_atx
  17. 17. DESIGN-FIRST ▸ Consistency for users ▸ Important for critical APIs ▸ Code-first can be expensive ▸ Gain the benefits of using OpenAPI @taylor_atx
  18. 18. 2. MOCKING AND FEEDBACK @taylor_atx
  19. 19. WHY Should YOU CARE ABOUT MOCKING? @taylor_atx
  20. 20. IF YOU WRITE DOCS, TUTORIALS, AND CONTENT, YOU CAN... ▸ Start writing sooner ▸ Give feedback ▸ Have more interactive docs @taylor_atx
  21. 21. IF YOU MAINTAIN CLIENT LIBRARIES OR SDKS, YOU CAN... ▸ More options ▸ Create libraries and SDKs faster ▸ Have libraries ready at release @taylor_atx
  22. 22. IF YOU CARE ABOUT DX, API DESIGN, ADVOCATE FOR USERS, YOU CAN... ▸ Power feedback loops with mocking ▸ Put real endpoints in front of users ▸ Go look up "API Design Using Feedback Loops," by Lorinda Brandon ▸ "Experimental APIs" @taylor_atx
  23. 23. "Experimental APIs are mock services that use simulated data to mimic API functions. They are designed with the goal of getting early feedback from the community around API desirability and design before the product release." -Capital One DevExchange, "Design Thinking and API Design" @taylor_atx
  24. 24. MOCKING ▸ Start with humans ▸ "What are the tasks users want to accomplish?" ▸ "Will the API help them achieve these tasks?" ▸ "Are the endpoints confusing?" @taylor_atx
  25. 25. SOME OF THE COMPANIES WITH PUBLIC OPENAPI SPECIFICATIONS ON GITHUB SendGrid (16 contributors), Azure (440 contributors), Slack, Stripe, NY Times, Flickr, Box, Adafruit, Kubernetes, Nexmo, Lufthansa, Netlify @taylor_atx
  26. 26. 3. TESTING @taylor_atx
  27. 27. TESTING ▸ Gain the benefits of it being machine readable ▸ All kinds of validation testing ▸ Prioritize the experience @taylor_atx
  28. 28. CONTRACT TESTING @taylor_atx
  29. 29. CONTRACT TESTING @taylor_atx
  30. 30. LESS SUPPORT OVERHEAD ! LESS CONFUSION AND HEADACHE ! HAPPIER USERS (INCLUDING YOU!) @taylor_atx
  31. 31. THE REALITY ! @taylor_atx
  32. 32. Photo by Jeremy Thomas
  33. 33. WHAT WOULD ALLOW YOU TO FOCUS MORE ON THE API experience? @taylor_atx
  34. 34. THANK YOU! ! @taylor_atx
  35. 35. @taylor_atx taylor@stoplight.io
  36. 36. APPENDIX: TOOLS THAT I MENTIONED ▸ Stoplight ▸ DapperDox ▸ ReDoc ▸ Prism ▸ Dredd @taylor_atx

×