Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auto-generated api docs, typed request objects, and request validation #73

Open
zRosenthal opened this issue Jul 31, 2018 · 2 comments
Open

Comments

@zRosenthal
Copy link
Member

  1. Typed Request Body
  • Request would become a generic class (or could create derived Requests classes)
  • Provide methods specifically for getting body, query, and path parameters to enable type checking
    • request.getBodyParam('could force this to be keyof BodyObject')
  1. Validating Request Body (maybe querystring and path params too)
  • A simple solution would be to provide a validate method in the abstract controller that accepts an object and a Class/Schema to validate against.
  • We can eliminate the need for calling a validate method by using decorators. We need a decorator to tell us what Class/Schema to validate against.
@Validate(SomeModel)
public getPerson(request: Request<SomeModel>) { }
  • Any implementation should allow the user to bring their own validator
  1. Generating api docs from requests and response objects (Add functionality for generating OpenAPI 3.0 docs #60 )
  • Having typed request and response objects is all but necessary for auto generating proper API Docs. Without them the user would need to define schema in decorators. I am against this as it can become error prone. I believe the code should always be the source of truth and we should do everything possible to eliminate a user from having to define things outside of normal code.
  • That being said, a solution is to add a script that can be ran at build time to parse all public methods in controllers and generate docs. In order for this to work the methods will need to use a generic Request object as described above. They would also do the same for a Response object.
  • The script could leverage some additional config (path to controllers, api name, etc) along with https://github.com/metadevpro/openapi3-ts to generate the api docs

I think these three things go hand and hand. A couple things to think about:

  • Do any of these things belong in the core library or are they better suited as extensions?
  • anything else?
@zRosenthal
Copy link
Member Author

@moraneva

@zRosenthal zRosenthal changed the title Feature Request/Proposal (three for one) auto-generated api docs, typed request objects, and request validation Aug 2, 2018
@zRosenthal
Copy link
Member Author

@moraneva @shametim would love an opinion on these things

zRosenthal added a commit to zRosenthal/mindless-1 that referenced this issue Apr 28, 2019
add functinality to support future features outlined in issue SpartanLabs#73

re SpartanLabs#86
zRosenthal added a commit that referenced this issue Jul 29, 2019
* feat(Request and App handler): Add ability for custom request deserialization and improve request ob

BREAKING CHANGE: Request class has changed

* test(Request and App): finsih updating request and app classes

add functinality to support future features outlined in issue #73

re #86

* refactor(request objects): change params, query string, and headers to be es6 maps

BREAKING CHANGE: must now pass headers and query string through as es6 maps

* build(typescript version bump): updated to latest stable typescript version 3.5.x

* docs(rejadme):
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants