Comments (7)
I'm looking for such a functionality as well.
I think the current approach is perfectly valid but it would be great to have the possibility to override the naming of a schema (using the terms of OpenAPI).
I'm happy to contribute if you provide me a direction on how you'd expect this feature to be implemented.
Some keypoints which come into mind:
- Should follow the test driven approach (no additional annotation processing etc)
- Should allow to document hierarchical object structures (how about inheritance & polymorphism ?)
- Intermediate format (resouce.json) needs to carry those information
- OpenAPI Spec generators needs to read those information (if present) and generate the according documentation
Maybe we can find an approach which allows the extension of schema details in the future:
Start with the naming of a schema and add additional options in the future
from restdocs-api-spec.
Thanks for your interest in this feature @thowimmer.
Sounds like a reasonable requirement. Currently we aggregate equal schemas. So it is not necessarily the case that each operation results in a set of schemas. So I am really not sure where to put such a function.
We need to keep the statement above in mind. This surely complicates things a little.
But generally I see two options:
Make the schema name an additional parameter that you can pass in your test
This would mean to add a schema name to ResourceSnippetParameters
so it makes its way into ResourceModel
and can thus be passed in the gradle plugin to OpenApi3Generator
and OpenApi20Generator
Implement plugable naming strategies
We could also invent a set of different plugable naming strategies that one would parametrize in the gradle plugin.
from restdocs-api-spec.
Many thanks for your proposed options.
I vote for option 1 because I think that we need a richer ResourceModel which contains additional schema options,
A richer resource model will allow additional features (not just naming) just like:
#97
I will try to come up with a PR where we can discuss this in more detail in the next few weeks :-)
from restdocs-api-spec.
Sounds like a reasonable requirement. Currently we aggregate equal schemas. So it is not necessarily the case that each operation results in a set of schemas. So I am really not sure where to put such a function.
But if you have an idea, feel free to give it a try.
from restdocs-api-spec.
It could be additional arguments in MockMvcRestDocumentationWrapper.document
to provide name of the request and response schema. Or maybe ResourceSnippetParameters.builder()
could have additional methods for specifying that?
from restdocs-api-spec.
PR #116 deals with this issue.
from restdocs-api-spec.
closed with #126
from restdocs-api-spec.
Related Issues (20)
- Share common attributes of extensions in the same class
- Please tell me how to make the api specification look better in swagger ui
- When i use webtestclient, i am getting on error message 'please use RestDocumentationRequestBuilders with urlTemplate to construct the request' HOT 1
- Replace TravisCI with GitHub Actions HOT 2
- OpenAPI 3 oauth2 security scheme not applied globally for all endpoints
- How to join documentation from multi-project build? HOT 1
- Limited supported constraints(PATTERN) in generated contract HOT 3
- Response Json Data 4Depth
- Keep supporting Spring Boot 2.7.x HOT 5
- Subschema examples
- openapi3 task null exception HOT 1
- Support License section of OpenAPI spec
- There is no way to indicate the requestBody is required
- Use general description, summary and operationId in generate openapi2 and postman
- Doesn't it support setting up authentication for cookies?
- Documenting Bean Validation constraints not supporting spring boot 3 HOT 1
- Could not find com.epages:restdocs-api-spec-openapi-generator:0.19.1 HOT 1
- Add support for communicating BigDecimal scale/precision using multipleOf
- Can you show an example of configuring `Contact`, `Server` in build.gradle.kts file?
- Could not find com.epages:restdocs-api-spec-openapi-generator:0.19.3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from restdocs-api-spec.