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.
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
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
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
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
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
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
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
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.