Describe Your API With OpenAPI (RESTFest 2019)

No matter how big or small your API, no matter the audience, internal or external, you need to provide clear and precise documentation so that others know how to use it. Since its inception as Swagger almost ten years ago, OpenAPI has been steadily gaining ground as the de facto specification for describing REST APIs. Whether your API is yet to be built or has been around for a decade, OpenAPI is a tool you can use to document all the parts of your APIs.

In this talk, I’ll introduce you to the basic concepts of OpenAPI, we’ll use it to create documentation for a simple API, and I’ll leave you with a few tips, tricks, and gotchas I’ve learned along the way. You should be able to take what you’ve learned and immediately begin describing your APIs with OpenAPI.

Transcript

1. Describe Your API With OpenAPI Ben Ramsey • RESTfest • Sep 28, 2019
2. Hi, I’m Ben. • Software Architect at ShootProof • Organizer at Nashville PHP • Hypermedia fan • ramsey/uuid library • Craft beer nerd • @ramsey on Twitter
3. OpenAPI
4. What is it?
5. Who’s behind it?
6. OpenAPI Initiative (OAI) openapis.org/about “The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how REST APIs are described. […] the OAI is focused on creating, evolving and promoting a vendor neutral description format.”
7. OpenAPI Specification (OAS) github.com/OAI/OpenAPI-Specification “defines a standard, programming language-agnostic interface description for REST APIs […] When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.”
8. • No need to rewrite existing APIs • Doesn’t require binding any software to a service • You don’t have to be the service owner to write a description for it • Allows for describing the service capabilities • Not all services can be described • Does not mandate a specific development process
9. Linux Foundation Collaborative Project openapis.org/faq “[Linux Foundation] Collaborative Projects are independently funded software projects that harness the power of collaborative development to fuel innovation…”
11. Swagger? • The OpenAPI Specification was originally created by SmartBear Software • It was originally named the “Swagger Specification” • SmartBear donated Swagger to the OAI at its inception
12. But don’t call it “Swagger”
13. What is Swagger now?
14. A set of tools for working with OpenAPI.
15. Version History
16. • Swagger 1.0 released in 2011 • Swagger 1.2 released as a formal specification in early 2014 • Swagger 2.0 released in late 2014 • SmartBear donated Swagger to the OAI on December 31, 2015
17. • OpenAPI Specification 3.0.0 released on July 26, 2017 • Followed by very minor patch releases: • 3.0.1 • 3.0.2 (current version) • OAI is currently working on version 3.1:
 https://github.com/OAI/OpenAPI-Specification/issues/1466
18. Boring! What does it look like?
19. paths: /pets: get: summary: List all pets operationId: listPets tags: - pets parameters: - name: limit in: query description: How many items to return at one time (max 100) required: false schema: type: integer format: int32 responses: '200': description: A paged array of pets headers: x-next: description: A link to the next page of responses schema: type: string content: application/json: schema: $ref: "#/components/schemas/Pets"
22. Parts of an OpenAPI Document • Name your root document openapi.json or openapi.yaml • Key properties: • openapi: The version of the OpenAPI specification you are using • info: Metadata about your API • paths: Describes all your endpoints and their request and response bodies openapi: "3.0.2" info: version: 1.0.0 title: Media Library description: |- This is an example API for [RESTfest](https://www.restfest.org). contact: name: Media Library Support url: https://example.com email: support@example.com license: name: MIT url: https://opensource.org/licenses/MIT paths: /book: get: summary: Get a list of books operationId: getBooks responses: 200: description: A list of books.
23. Tips, Tricks, & Gotchas
24. $ref paths: /book: get: summary: Get a list of books operationId: getBooks responses: 200: content: application/json: schema: title: List of Books type: array items: $ref: "#/components/schemas/book" components: schemas: book: title: Book type: object properties: title: title: Name of the book type: string
25. Inheritance? • Not exactly. • JSON Schema provides boolean logic for subschemas. • anyOf • oneOf • allOf • Some use allOf to provide a kind of inheritance, but it can lead to logical impossibilities.
26. Inheritance? • Not exactly. • JSON Schema provides boolean logic for subschemas. • anyOf • oneOf • allOf • Some use allOf to provide a kind of inheritance, but it can lead to logical impossibilities. anyOf: - type: string maxLength: 5 - type: number minimum: 0 anyOf Passes “short” 12 Fails “too long” -5
27. Inheritance? • Not exactly. • JSON Schema provides boolean logic for subschemas. • anyOf • oneOf • allOf • Some use allOf to provide a kind of inheritance, but it can lead to logical impossibilities. type: number oneOf: - multipleOf: 5 - multipleOf: 3 oneOf Passes 10 9 Fails 2 15
28. Inheritance? • Not exactly. • JSON Schema provides boolean logic for subschemas. • anyOf • oneOf • allOf • Some use allOf to provide a kind of inheritance, but it can lead to logical impossibilities. allOf: - type: string - maxLength: 5 allOf Passes “short” Fails “too long”
29. Inheritance? • Not exactly. • JSON Schema provides boolean logic for subschemas. • anyOf • oneOf • allOf • Some use allOf to provide a kind of inheritance, but it can lead to logical impossibilities. allOf: - type: string - type: number allOf Fails “a string” Fails 42
30. Recursion components: schemas: book: title: Book type: object properties: title: title: Name of the book type: string relatedBooks: type: array items: $ref: "#/components/schemas/book"
31. Custom Properties • OpenAPI allows extension through x-properties. • Example:
 
 x-beta: true • Custom properties have no meaning to tools and documentation- generators, unless you write your own logic for them.
32. Let’s Build an API!
33. Tools • Documentation: • Swagger UI: swagger.io/tools/swagger-ui/ • ReDoc: github.com/Rebilly/ReDoc • Stoplight Studio: https://stoplight.io/studio/
34. Tools • Much more: • Validators • Testing tools • Parsers • Mock Servers • Check out openapi.tools by Matt Trask and Phil Sturgeon
36. Resources • OpenAPI Initiative: https://www.openapis.org (note the “s”) • OpenAPI Specification: http://spec.openapis.org/oas/v3.0.2 • Repository: https://github.com/OAI/openapi-specification/
37. Thank you! benramsey.com ben@benramsey.com @ramsey on GitHub @ramsey on Twitter @ramsey@phpc.social on Mastodon