The Controller is meant to handle incoming requests and route to the appropriate business login
- Version: 0.1.0
This module should be imported into an api and initialized.
go get github.com/wepala/weos-controller
Then setup a configuration file api.yaml
for example
openapi: 3.0.2
info:
title: WeOS REST API
version: 1.0.0
description: REST API for passing information into WeOS
x-weos-config:
session:
key: "${SESSION_KEY}"
path: ""
logger:
level: ${LOG_LEVEL}
report-caller: true
formatter: ${LOG_FORMAT}
applicationId: ${APPLICATION_ID}
applicationTitle: ${APPLICATION_TITLE}
accountId: ${ACCOUNT_ID}
database:
host: ${POSTGRES_HOST}
database: ${POSTGRES_DB}
username: ${POSTGRES_USER}
password: ${POSTGRES_PASSWORD}
port: ${POSTGRES_PORT}
middleware:
- RequestID
- Recover
- Static
jwtConfig:
key: ${JWT_KEY}
tokenLookup: ${JWT_LOOKUP}
claims:
email: string
real: bool
authScheme: ${JWT_SCHEME}
contextKey: ${JWT_CONTEXT}
signingMethod: ${JWT_SIGNING_METHOD}
paths:
/health:
summary: Health Check
get:
x-weos-config:
handler: HealthChecker
responses:
"200":
description: Health Response
"500":
description: API Internal Error
/admin:
summary: Admin Endpoint
get:
x-weos-config:
group: True
middleware:
- Static
responses:
200:
description: Admin Endpoint
NB: The content of the yaml can also be passed into the Initialize
method
The configuration uses the OAS 3.0 api specification. Using a standard format allows
us to take advantage of the rich tooling that is available. WeOS specific configuration can be found under the weos
specific configuration extension x-weos-config
. When this extension is applied to a path, the configuration details
is available as a path config.
Getting mock responses couldn't be easier.
THIS IS CURRENTLY NOT SETUP FOR THE NEW DIRECTION
In your api yaml there are a couple ways you can setup mock responses;
- Don't configure the path with a
x-weos-config
(it will automatically return example responses you have defined on the path or on the component schema of the response) - Setup a sub property
mock
to true on thex-weos-config
Example Mock Config
openapi: "3.0.0"
info:
version: 1.0.0
title: Basic Site
paths:
/:
get:
summary: Landing page of the site
responses:
'200':
description: Landing page
content:
text/html:
example: test
schema:
type: string
/about:
get:
summary: About Page
x-weos-config:
mock: true
handler: HelloWorld
responses:
'200':
description: About Page
content:
text/html:
example: test
schema:
type: string
You can define mocks in a few ways
example
under content in the responseexamples
these are named examplesexample
on the component
Read more about examples in swagger - https://swagger.io/docs/specification/adding-examples/
There are a few options you can use when making a mock request
X-Mock-Status-Code
- Use this to specify the response code you'd like to receive (this is if the path has multiple responses defined)X-Mock-Example
- Use this to specify which example should be used (this is when theexamples
option is used on the response)X-Mock-Example-Length
- Use this to specify the amount of items to return (this is useful when the response is an array)X-Mock-Content-Type
- Use this to specify the content type desired. (This is required if there are multiple content types defined)
This project uses gitflow workflow
- Clone the repo to local
- Create feature branch from dev branch (e.g. feature/WEOS-1)
- Push the feature branch to the remote
- Create PR from the ticket branch to dev branch
- When the item is merged to master it will be deployed
To aid with this use the git flow cli (you will be able to create feature branches e.g. git flow feature start APO-1)
- Admin - Akeem Philbert akeem.philbert@wepala.com