npm install -g yo npm install -g generator-swaggerize 

git clone https://github.com/MichaelDimmitt/simp-example-swaggerize-express.git; cd simp-example-swaggerize-express yo swaggerize *when prompted input:* openapi.json for testing purposes, answer all additional questions with "fred" -will still work. cd fred 

 cd into (app name) cd into handler folder NOTE: handler folder is your request comes in and your response ships out. GET REQUESTS: request, stored as "req" comes from the url where key and value queries are communicated. response, stored as "res" 

by default config/swagger.json has all the answers for the backend developer this is your api or as the autogenerated readme declares, Swagger api [location](./fred/config/swagger.json) Three sections make up this example url, http://localhost:8000/v1/pets?limit=10 base-url notice baseURL in this case is v1 paths notice path in this case is pets parameters notice parameter in this case is "name": "limit", 

cd fred open http://localhost:8000/v1/pets?limit=10; npm start 

 consuming these endpoints, I am considering keeping all of this in the same repo. the api autogenerates in a subfolder. therefore the rationale is the consumer as an adjacent folder. eager for feedback. elsewise the consumer could exist in another repo. 

req ... comes in as an object whose keys can be accessed with "."'s instead of the entire request object. ofen req.query is used. req.pathname leads to the autocreated handler file and therefore not always required. for your viewing purposes, a full req object availiable in the repo folder. This is most simular to web scraping objects. in that the whole object is not required but everything is given. you can add a new handler by modifying config/swagger.json adding the path and then adding the file that would correspond with that path.