The most surprising thing about testing GraphQL APIs with Postman is how easily you can break free from the rigid, request-response cycles of REST and truly explore the interconnectedness of your data.
Let’s see it in action. Imagine you have a GraphQL API for a simple blog. You can query for all posts, or a specific post by its ID. You can also create a new post, or update an existing one.
Here’s a Postman request set up to query for all blog posts:
{
"query": "query { posts { id title content } }"
}
And here’s how you’d query for a specific post, say with ID 123:
{
"query": "query GetPost($postId: ID!) { post(id: $postId) { id title content } }",
"variables": {
"postId": "123"
}
}
Now, let’s look at mutations. To create a new blog post:
{
"query": "mutation CreatePost($title: String!, $content: String!) { createPost(title: $title, content: $content) { id title content } }",
"variables": {
"title": "My New Blog Post",
"content": "This is the content of my new post."
}
}
And to update an existing post with ID 456:
{
"query": "mutation UpdatePost($postId: ID!, $title: String) { updatePost(id: $postId, title: $title) { id title content } }",
"variables": {
"postId": "456",
"title": "Updated Blog Post Title"
}
}
The real power comes when you chain these together. You can query for a post, then use its ID in a mutation to update it, and then query again to verify the change. Postman’s collection runner and scripting capabilities make this seamless.
Consider this workflow:
- Query for a post: Get the
idof a post that exists. - Update the post: Use the
idobtained in step 1 to change itstitle. - Query for the same post again: Verify that the
titlehas indeed been updated.
This is achievable using Postman’s pre-request scripts and test scripts. You can store the id from the first response in a collection variable, and then use that variable in the mutation and subsequent query.
The mental model for GraphQL is one of a graph of interconnected data. Your API endpoint is a single entry point, but instead of fetching pre-defined resources (like in REST), you’re traversing this graph. You specify exactly which nodes (fields) you want, and the server resolves them. Mutations are operations that change the state of this graph.
When you define a GraphQL schema, you’re essentially defining the shape of your data graph. Queries allow you to read from this graph, while mutations allow you to write to it. The beauty is that you can request deeply nested data in a single query, avoiding the over-fetching or under-fetching common with REST APIs. For example, you could fetch a post and all its comments in one go:
{
"query": "query GetPostWithComments($postId: ID!) { post(id: $postId) { id title content comments { id body author } } }",
"variables": {
"postId": "123"
}
}
The way GraphQL resolves fields is through a concept called "resolvers." For each field in your schema, there’s a corresponding function on the server that knows how to fetch the data for that field. When you make a query, the GraphQL server executes these resolvers in a way that’s efficient and returns precisely what you asked for. You don’t need to worry about how the server is joining tables or fetching data from different microservices; that’s abstracted away by the GraphQL layer.
A common misunderstanding is that GraphQL itself is a database. It’s not. It’s an API query language and a runtime for executing those queries. The actual data storage and retrieval logic resides in your backend services, exposed via GraphQL resolvers. This separation of concerns is key to its flexibility.
The next step in mastering GraphQL with Postman is exploring subscriptions for real-time data updates.