Documentation
/
NameSpaces
NameSpaces
v0.00
TypeScript
Wappi has a very Strict folder structure.
If you try and add files and folders everywhere like a cowboy, then you will probably break your API and also create your future self more problems.
Example Endpoint: User_UpdateDetails_2_3_4
| Namespace | Function | Version |
|---|---|---|
| User | UpdateDetails | 2.3.4 |
The initial folder is the namespace.
Think of this folder like a micro-service, just without the -service at the end.
So in a micro-service architecture, to have an endpoint that updates all the details of a user, you might store that code in a service like: User-Service.
In wappi, just make the namespace folder User
Then all your User endpoints will be nested under here.
Clean and simple.
The second folder is the endpoint name. This is the descriptive name of the function/endpoint.
This can be anything you like, that describes the purpose of the endpoint for the API user.
In your User service your endpoint name would be: UpdateDetails
The last part of the folder structure is made up of 3 numbers: 2.3.4
These are the versions of endpoint. Think of this like: Every microservice endpoint will have it's own version that is immutable. Thats what this last folder structure is.
| Major Version | Minor Version | Patch Version |
|---|---|---|
| 2 | 3 | 4 |
Make your namespace names be specific for a purpose. So it is easy to find where new endpoints should live.
Good examples: User || Products
Bad examples: Services || AWS
If you make it too broad, or if you name it based on something like AWS. It will be confusing to new developers on what should go in this, or why a function is in there.
Make your function name descriptive to what it does. This will make it easier for the future YOU, to work out what it does, as well as all the other API users trying to find the right endpoint.
Good examples: UpdateDetails or UpdateCartAddressDetails
Bad examples: Update or Get
If you make it really generic, you will eventually find that you have too much logic in 1 endpoint. Which makes it complicated. And things that are complicated, tend to have more tech debt, and break more often. So keep it simple.