Closed bajtos closed 3 years ago
Related:
@requestBody
#3496This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS
file at the top-level of this repository. This issue will be closed within 30 days of being stale.
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS
file at the top-level of this repository.
Suggestion
At the moment, it's cumbersome to describe a request-body parameter with a schema built from a model with custom options.
See e.g. https://github.com/strongloop/loopback-next/pull/3199
Let's find a more concise way how to describe such request bodies.
Examples
Few of many possible solutions:
1) New decorator
2) New helper
Important considerations:
We should keep the decorator decoupled from the helper generating the schema. This is important to allow interoperability with 3rd party ORMs like TypeORM and to keep it easy for users to provide a custom schema (e.g. hand-written, not generated).
In the future, we may add support for parsing XML requests. Ideally, the new helper should be designed in such way to support that addition in the future, without any changes needed in the controller code. I.e. the new helper should not be tied to JSON content-type, but instead should be prepared to be extended by additional content-types like XML in the future.
The example snippets above meets both criteria.
Acceptance criteria