POST/CON 2019 Workshop: Design, Develop, and Mock APIs with Postman
•Download as PPTX, PDF•
2 likes•880 views
Learn how to collaboratively plan and design APIs to establish a single source of truth for your API lifecycle. This workshop will focus on building Collections to represent APIs from the point of view of both producers and consumers of an API. We will show how you can use API schemas (OpenAPI/RAML/GraphQL) in Postman, manage versions of collections, and document them. We will also deep-dive into Mock Servers, and show how you can use them in your development.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to POST/CON 2019 Workshop: Design, Develop, and Mock APIs with Postman
Similar to POST/CON 2019 Workshop: Design, Develop, and Mock APIs with Postman (20)
More from Postman
More from Postman (20)
Recently uploaded
Recently uploaded (20)
POST/CON 2019 Workshop: Design, Develop, and Mock APIs with Postman
- 1. PRESENTED BY Design, Develop & Mock APIs with Postman Kaustav Das Modak Developer Advocate, Postman @kaustavdm
- 2. Concepts • Real-life API collaboration • API Design: What we need • Postman fundamentals Role: Producer • Creating collections and Mocks • Using “API” and schema Role: Consumer • Using Mocks • Collaborating with producer What we will cover
- 4. Let’s talk about APIs
- 5. An application today is built of multiple interacting components
- 6. s talk to each other, we should carefully design how
- 7. Design your APIs before you implement them
- 8. omain boundaries and data models before you impl Collaborate Business use case Abstraction Encapsulation Entities Resources Data structures
- 9. Design Implementation Data models Business logic Publish Code
- 10. A good design should adapt to changes
- 11. Key concepts
- 12. If you work with APIs…
- 13. What is an API? Interface Implementation Instance Schema OpenAPI RAML GraphQL Postman Code Databases Repositories Microservices … Deployed Interface + Implementation + Servers …
- 15. Scopes Private Partner Public More potential consumers
- 16. Schema OpenAPI 2.0 | 3.0 GraphQL RAML Postman Collections WSDL API Blueprint
- 17. Producers How do we gather requirements? How do we share API docs? How do we collect feedback? Consumers How do we give our inputs? How do we consume docs? How do we test our requirements? Questions to ask
- 18. Design the interface Write API schema Build a testable, executable spec Collaborate on decisions Document the interface Resource & usage descriptions Request/Response examples Collaborate on implementation API Mocks API Contracts What we need for effective API design
- 19. What is the single source of truth?
- 20. Part 2: Setting things up
- 21. GET postman.com
- 22. Design API for a hypothetical service to manage list of cats. As both producer and consumer. What we will build today
- 23. Routes: - GET /cats Returns list of all cats - POST /cats Add a new cat Cat schema: - id: Integer - name: String - breed: String - age: Integer v0.1
- 24. Routes (new): - GET /cats/{{catId}} Find a specific cat v0.2
- 25. Part 3: Postman fundamentals
- 26. Collections Group and organize your requests into meaningful collections.
- 27. Variables Foundation of dynamic values for requests. Can be manipulated programmatically.
- 28. Workspaces • Organised by service and function • Service producers and consumers share their collections in them
- 29. Pre-request Script • Written in JavaScript • Executed in a sandboxed NodeJS environment • Executed before request is sent • Modify request through variables
- 30. Tests • Written in JavaScript • Executed in a sandboxed NodeJS environment • Executed after response is received • Can have assertions • Quick-start snippets
- 31. Postman API Programmatically interact with elements in the Postman ecosystem api.getpostman.com
- 32. Blueprints • Collections created by service producers to describe an API • Includes examples of each request to document responses
- 33. Mock servers • Created by service producers from blueprint collections • Used by service consumers to test API contracts
- 34. Comments • To make contextual comments and tag other team members in collections, in the app, and in the browser • Used to negotiate API design among stakeholders
- 35. Questions? (and a quick break)
- 36. Part 4: Role - API Producer
- 37. • Build a blueprint collection • Add requests • Add documentation • Add examples • Success cases • Failure cases • Share collection in Workspace • Comments on requests Create blueprint collection
- 38. • What is a Mock Server? (Recap) • Create a mock server from Blueprint collection • Execute Blueprint collection against Mock Create Mock Server
- 39. • Create a new “API” • Add OpenAPI 3.0 YAML schema • From: bit.ly/postman-api-yaml • File: api-v0.1.yaml Create “API” and schema
- 40. • Edit API version tag to v0.1 • Add blueprint collection and mock to API v0.1 Use versioning
- 41. Questions? (and another quick break)
- 42. Part 5: Role - API Consumer
- 43. • Build contract collection based on blueprint collection • Send requests to Mock endpoint • Save and document requests • Add tests to assert on response • Switch base URL using environments Using Mocks as a consumer
- 44. Part 6: Work with versions
- 45. • Create v0.2 for the API • Update OpenAPI schema • From: bit.ly/postman-api-yaml • File: api-v0.2.yaml • Update blueprint • Update contract • Tag collections with new version Create v0.2
Editor's Notes
- APIs are the building blocks of modern software. Multiple services, spanning multiple teams and multiple geographical regions. Developing those services in parallel without teams blocking others is a challenge that teams face often.
- In a world where systems talk to each other, it is vital to carefully design how these systems will interact. It is terribly easy to get lost in the quagmire of multiple services and multiple dependencies and who does whom.
- In a world where systems talk to each other, it is vital to carefully design how these systems will interact. Instead of the traditional code-first approach to software development, API-first development is a software development pattern which asks you to design and scope out your APIs before you build the software.
- Gist of API-first design Allows stakeholders to add their inputs.
- Separating the design of the API from its implementation, the architect is constrained only by the data model and business logic. Your API can now evolve unfettered by any existing user interface or legacy engineering frameworks.
- Caveat: Make sure you design APIs in a way that they remain flexible to future changes.
- When people talk about APIs, sometimes they talk about the implementation or the code, sometimes they’re referring to the interface, and sometimes they’re referring to the hosted version of the service.
- Producer: Who builds and serves an API Consumer: Who uses that API for their work
- Arrow follows more number of potential consumers
- Callout: How many of these have you worked with? Any ones that you know are missing from this list?
- Make sure you have the latest version of Postman app installed Create account. Signin.
- We will focus on the API interface design. Not the code for actually building the service. In the process we will use Postman’s Mock Servers to serve as a backend.
- A quick overview of the Postman features we will need to build the rest
- Workspaces form the foundation of collaboration for our teams.
- Every single request can have tests. Foreshadowing: Just like variables, tests can also be written at collection and folder levels.
- Every single request can have tests. Foreshadowing: Just like variables, tests can also be written at collection and folder levels.
- Collections that serve as API reference Provides request and response structure (Usually) First piece in the design phase of an API
- More on contracts later.
- One of the newer features in Postman Comments in collections make discussions contextual. Postman is invested in improving this feature. Again, dogfooding here helps us understand the scopes for improvement.