zzAPI (prounounced like pizza, the syllables interchanged) is an HTTP (REST) API documentation and testing tool, a very simplified version of Postman. It uses zzAPI core as the underlying engine.
This extension makes it easy to create, document and test API requests from within the IDE. Request bundles are YAML files with the .zzb
extension.
.zzb
file (essentially a YAML with a schema) is opened. Click these to run the request. Responses are shown in a new editor window, you can save these as sample responses..zzv
files (global), or they can be local to the bundle in the variables
section. Thus, you can share variables also with your team..zzv
file and do not commit it to the repository.doc-
nodes, or just use simple YAML comments using # comment
syntax.requests:
simple-get:
method: GET
url: https://postman-echo.com/get
params:
foo1: bar1
.zzb
file extension to activate the extension.zzAPI: Import Postman collection
.zzb
extensionrequests
node, to run all the requests sequentially. Click on these to execute them and see the response.requests:
simple-post:
method: GET
url: https://postman-echo.com/post
headers:
Content-type: application/json
Authorization: Basic Xfj34$fe
body:
foo1: bar1
foo2: [ bar2, bar3 ]
requests:
get-with-params:
method: GET
url: https://postman-echo.com/get
params: { foo1: bar1, foo2: bar2 }
tests:
status: 200
$.args.foo1: bar1
$.args.foo2: bar2
$.
are JSON Path specs into the response body, if it is JSON, and the RHS is the expected value.status
), the entire body as a string (body
) and headers (spec starts with $h.
) can also be tested.$.value: {$gt: 43}
are also supported (similar to MongoDB filter syntax).Within the bundle:
variables:
staging:
server: https://staging.example.com
expectedUserId: 12345
production:
expectedUserId: 45678
server: https://www.example.com
In a separate .zzv
file (shared across multiple bundles in the directory):
staging:
user: staging-user
password: staging-password
production:
user: user
password: password
.zzv
file(s) for variables that are common across bundles.zzv
file to store secrets and passwords, do not commit to the repositoryaddressVar: { street: "36, Chowringee lane", city: Kolkata }
)requests:
get-with-params:
method: GET
url: https://example.com/login
params: { userId: bar1, password: bar2 }
setvars:
userName: $.data.name
body
) and headers ($h.content-type
) alsorequests:
login:
url: $server/login
method: GET
params: { user: $user, password: $password }
tests:
status: 200
$.userDetails.userId: $expectedUserId
$variable
syntaxabc$(variable)def
body: { address: $addressVar }
and the variable will retain its defined type.requests:
simple-get:
url: $server/get
method: GET
params: { foo: foo%20bar }
options:
rawParams: true
follow: true
common:
baseUrl: https://postman-echo.com
headers:
Content-type: application/json
tests:
status: 200
options:
follow: true
requests:
Simple GET:
url: /get
method: GET
common
section for all common things.baseUrl
for a common prefix across all requestsbaseUrl
will be ignored if the request URL does not start with a /
. simple-get:
url: $server/get
method: GET
params: { foo: bar }
response-normal: file://./responses/normal.json
response-failure: file://./responses/failure.json
response*
nodes. Use a file://
format.file://...
links to open the sample (VS Code does this for you!)The extension works with .zzb
files, which are YAML request bundles as described here.
You can use variables within the bundle, and also common variable set files and environments as described here.
You can best learn about the .zzb
file format by just browsing the bundle used for comprehensively testing zzAPI itself: tests-bundle.zzb.
Instead of the raw body, the request body can be a YAML/JSON object. This is a great convenience compared to other API tools, where need you to create valid JSONs with quotes around every key and string. YAML is much easier to hand-create.
Non-JSON body can be specified as a string. A lengthy body with multiple lines can be written using the JSON multi-line string syntax:
body: |-
<xml>
<node value="x"/>
</xml>
Save the bundles along with your code and commit them to your repo. This is how you share them with your team. Also keep the tests right next to the code.
Multiple variable files are merged. Keep one set as your secrets or personal set where you specify your passwords etc. needed for the requests. Do not commit this to your repo.
Create multiple bundles within the same directory and share the variable sets among them. Or, if you prefer, declare variable sets within the bundle itself for easy visibility. Note that bundle variables override variables defined in .zzv
files.
Create one bundle for each test case or flow. Use Run All Requests to run all of them together and see their pass/fail status in the output window. Create a separate bundle with lots of comments for documenting your API set and for others to try out.
Use JSON Path Online Evaluator to play with JSON path before using them in tests and setting variables from the response body.
For CI/CD and test automation, check out the command-line version: https://www.npmjs.com/package/zzapi-cli and https://github.com/agrostar/zzapi-cli
To appreaciate, give us a star in the GitHub repo: https://github.com/agrostar/zzapi-vscode and/or in the VS Code marketplace: https://marketplace.visualstudio.com/items?itemName=AgroStar.zzapi
For bugs, improvements and feature requests, create a new issue here: