Every endpoint has a version. So you don't have to break APIs when you deploy a new fix.
When you deploy a wappi API, you won't break your frontend or existing code, because the version is a self-contained micro-service. Not worrying about anything outside of itself.
Every endpoint has a strict folder nesting, to keep things clean and tidy.
See Structure > NameSpaces
The version is the last folder where your endpoint code lives.
This keeps different changes separate and clean.
Every time you create a new endpoint or a new version. You must use the wappi CLI so that everything that is supposed to happen, happens.
Saves you forgetting to do one thing, then wondering why nothing works.
Simply run the following CLI command to create a new version. (c is short for create)
1npx wappi cThen when prompted, select the current endpoint you want to version.
This will give you the option to copy the current endpoint or start again.
It will also allow you to create a major, minor and fix version.
A version is made up of 3 numbers: 2.3.4
| Major Version | Minor Version | Patch Version |
|---|---|---|
| 2 | 3 | 4 |
| Breaks Version 1 | Recommended Update | Patching the current version, But can have side effects |
If you change a major version 2.3.4
Make sure that old versions are still compatible and document the breaking change properly.
No developer wants to use your API and then one day it all breaks, because they didn't know the version of the API they were using was deleted.
After an API has been used for years, you may find you have hundreds of versions of endpoints.
Use the logging, to find out which versions are still being used. Then delete the versions that are extinct.